See the attached screenshot, this is how both the print preview and the
actual printout on paper look like. All the characters are consistently
replaced with another one.

This is a gedit with default settings (the font it tries to use for the body
is "Monospace 9"), but I've heard about exactly the same printing problem in
evolution.

I don't know if gnome-print is the place of the bug, it was just a guess, but
I have no better idea. I have gnome 2.12.1, libgnomeprint and libgnomeprintui
are also numbered as 2.12.1.

Here's what I managed to debug:

With (nearly?) any other font instead of the default Monospace the characters
are okay in print (but of course not fixed-width).

I have X.Org 7.0 and its fonts are installed to /usr/share/fonts. Hence there
are several subdirectories here, including /usr/share/fonts/TTF and
/usr/share/fonts/Type1. Neither of these two directories are mentioned in my
xorg.conf, but it did't seem to matter.

If I remove one of these two directories (either TTF or Type1), or even both
of them, and run "fc-cache -f" as root, then printing (as well as the preview)
is perfect in gedit (as well as in evolution, as reported by that user). The
bug only appears if both of these two directories are present there and
mentioned in fonts.cache-[12].

(I've tested this whole issue with fontconfig 2.2.3, 2.3.2 and 2.3.94, they
do not make any difference.)

However, if both the TTF and Type1 directories are present there, then there's
still a 50% change that you won't hit this bug. Up to now fontconfig has
scanned the directories in random (filesystem) order. (See the thread at
http://lists.freedesktop.org/archives/fontconfig/2006-March/002154.html
for a short discussion about it).

On my machine, this random order happens to be TTF prior to Type1. So
fonts.cache-1 has TTF first and Type1 later. In this case printing is buggy.
However if I swap these two entries in fonts.cache-1 (with fontconfig<=2.3.2)
then printing is okay.

According to fonts.{dir,scale} these two directories both implement
-b&h-luxi mono-[blahblah...] fonts in different formats. I'll attach strace
output which shows that in the buggy case fonts from both directories are
being opened. Hence I have a strong feeling that some piece of printing
software just cannot decide which one of the two implementations of the same
font to use and mixes them. Maybe it takes the font shape from one of them
and the encoding table from the other, or something similar, which leads to
this bug.

If and only if printing is buggy in gedit, it also prints many lines like
these ones to stderr:

(gedit:2642): GnomePrint-CRITICAL **: gnome_rfont_get_glyph_stdadvance: assertion `glyph < GRF_NUM_GLYPHS (rfont)' failed

(gedit:2642): GnomePrint-CRITICAL **: gnome_rfont_get_glyph_stdbbox: assertion `glyph < GRF_NUM_GLYPHS (rfont)' failed

(gedit:2642): GnomePrint-CRITICAL **: gnome_rfont_render_glyph_rgb8: assertion `glyph < GRF_NUM_GLYPHS (rfont)' failed