Bug 54

Created attachment 38 [details]
Screen shot showing misalignment due to bad width of 'e' chars

Ok, I did a little more investigation.  Something interesting is
happening, so I'll post what I've noted in case it gives some clue.

I originally thought only a few characters had 'wrong' widths, but
it turns out it is more common than I thought.

It seems that the characters are being displayed with one of only three
different widths, with ratios of approx 0.89, 1.0 and 1.1.  I chose
1.0 for the middle width as that seems to be the most common.

For example I did a quick survey of the characters: <space>,0..9,a..z,A..Z
Characters with the thinnest of the three widths are: 03begoprtyCEFLSVW
Characters with the thickest of the three widths are: 7vIN
All the rest have the nominal width.  I'm sure this info is not important
in itself, but it is interesting that there seems to be three widths only.

One more bit of info before I give up on this for tonight...

I performed the same experiment on another application, Mozilla (xft version),
and got different results.

For the sample text shown in the screenshot, the 'T' and 'e' were okay (or
rather had matching widths), but this time the 's' was wrong.

So I tried the survey of characters.  Again I found there were three different
widths, but the mix of characters with each width was completely different.

It looks like the width's aren't quite monospaced, but only close.

You can force this font to be monospaced if you like by setting 
the spacing attribute to mono (this is untested):

<match target="font">
   <test name="family">
      <string>Letter Gothic MT</string>
   </test>
   <edit name="spacing">
       <const>mono</const>
   </edit>
</match>

In any case, the bug is either in the font, FreeType or perhaps Xft, not
fontconfig...

Sorry, The impression I got was that this bugzilla was for reporting bugs
in both fontconfig /and/ Xft.

I doubt the bug is in the font - I've never seen this problem anywhere when
I've used it in windows.  And windows mozilla renders my tests okay.

I'll investigate further to try and determine whether the fault is with Xft
or Freetype.  If it turns out to be Xft, where should I report the bug?

oops.  Sorry, I didn't look at the Product field.  Yes, this is the right place
to report Xft bugs.  Did you give the suggested fonts.conf excerpt a try?  If it
fixes the problem, then we've likely got an issue with FreeType.  Xft just takes
the spacing values from FreeType and rounds them to the nearest pixel value;
even if that rounding is 'broken', a monospaced font should present the same
spacing values for each glyph and the spacing should still be consistent.  What
is possible is that the font relies on hinting to set the widths to the same
value, and that the version of FreeType you are using has the bytecooe hinting
interpreter disabled due to patent concerns.

The fonts.conf hack did have an effect.  It made everything
equal width, but the width was too great - almost doublespaced.

I assume RH8 ships with a bytecode-disabled freetype.  So when I get
a spare moment I'll try upgrading freetype and see what effect it
has.

Okay, I installed a fresh (ie non RH) freetype 2.1.3 with bytecode
interpreter enabled.  The font is now being rendered correctly.

So it seems your guess was correct.  I guess this is one good reason
not to use the autohinter. :)  

Thanks for your help Keith.

Well, at least we know where the "bug" lies then.  Thanks for figuring it out.

Mass update: Close all bugs resolved over one year ago.

*** Bug 75999 has been marked as a duplicate of this bug. ***