Comment 6 for bug 447961

Hin-Tak Leung and Steve White had more discussion and this has resulted in a workaround to be applied to texttopdf in the cups package. See Hin-Tak's e-mail below. The workaround is a one-byte change which I have tested now on both Karmic and Lucid where it actually solves the problem. Therefore I add a cups task for applying this workaround and nominated the bug for Karmic to include this workaround in the upcoming SRU for CUPS.

----------

Till,

I and Steve had a bit more correspondence since that e-mail. texttopdf uses the width of glyph 0 (the ".notdef" glyph) to work out the layout,
and for some reason the first few glyphs of recent FreeMono have very strange widths according to texttopdf's debug code e.g. "364 0 333 600" . freetype's ftdump also don't think it is a monospace font (possibly by a similiar method, checking the first few glyphs) so texttopdf is not alone in seeing variable widths. I sent those debug code to Steve yesterday to see if he can figure out what's going on. He noticed the ttf's real glyph data only starts at glypth 3, and the other values are supposedly made up by fontforge, so it might turn out to be a fontforge bug. (fontforge is used to generate the ttf's from sfd's.).

Meanwhile I have thought of another solution - you can replace the zero in
otf_get_width(otf,0) around texttopdf.c:1090 by say, 4. I just tried 4 here and it does the job. It doesn't matter what number it is, since a good monospace font should have the same width for most of its early glyphs. This is also a change that won't break if/when you get an updated FreeMono or use some other monospace font. (some glyphs have zero widths, like the diacritics - i.e. accent symbols which runs on top of regular glyphs, but those aren't in the beginning of the glyph list; the rest should all have the same width). I suggest you push that out as a work-around for the time-being, until the font issue itself is resolved one way or another, to keep the users happy.

Cheers,
Hin-Tak