Bug 52167 (suse37167)

<!-- SBZ_reproduce  -->
mfabian@magellan:~$ fc-list "Nimbus Mono L" family style spacing file
/usr/X11R6/lib/X11/fonts/URW/n022023l.pfb: Nimbus Mono L:style=Regular Oblique
/usr/X11R6/lib/X11/fonts/URW/n022004l.pfb: Nimbus Mono L:style=Bold
/usr/X11R6/lib/X11/fonts/URW/n022003l.pfb: Nimbus Mono L:style=Regular:spacing=100
/usr/X11R6/lib/X11/fonts/URW/n022024l.pfb: Nimbus Mono L:style=Bold Oblique
mfabian@magellan:~$ fc-list "Luxi Mono" family style spacing file
/usr/X11R6/lib/X11/fonts/truetype/luximb.ttf: Luxi Mono:style=Bold
/usr/X11R6/lib/X11/fonts/Type1/l047013t.pfa: Luxi Mono:style=Regular:spacing=100
/usr/X11R6/lib/X11/fonts/truetype/luximri.ttf: Luxi Mono:style=Oblique:spacing=100
/usr/X11R6/lib/X11/fonts/Type1/l047036t.pfa: Luxi Mono:style=Bold Oblique
/usr/X11R6/lib/X11/fonts/truetype/luximr.ttf: Luxi Mono:style=Regular:spacing=100
/usr/X11R6/lib/X11/fonts/Type1/l047016t.pfa: Luxi Mono:style=Bold
/usr/X11R6/lib/X11/fonts/Type1/l047033t.pfa: Luxi Mono:style=Oblique:spacing=100
/usr/X11R6/lib/X11/fonts/truetype/luximbi.ttf: Luxi Mono:style=Bold Oblique
mfabian@magellan:~$

the spacing values are apparently calculated in 

FcFreeTypeCharSetAndSpacing (FT_Face face, FcBlanks *blanks, int *spacing)

in fcfreetype.c in the fontconfig sources.
Either this calculation is broken or the fonts are broken. 
My guess is that there is a subtle problem with these fonts.

Any Progress? 

Still valid? 

* This comment was added by mail.
ihno> Still valid?

Yes.

I want to update fontconfig during the next days, maybe that
helps, but somehow I doubt it. Currently I guess the problem
is in the fonts.

The problem is still there after updating to fontconfig-2.2.99.20050218-2.

The problem still exists with freetype 2.1.10 and fontconfig 2.3.2.20050712.

The problem is not caused by freetype or fontconfig, it is really
a problem in the fonts.

Created attachment 41873 [details]
debug.patch

Patch for fontconfig to generate some debug output.

To check the advance values of a font, use fontconfig with that patch
applied and:

   - create an empty directory
   - copy the font to check in that directory
   - run "fc-cache -f . " in that directory

Created attachment 41880 [details]
debug.patch

Improved debug.patch which works for several fonts in a directory
and prints the family name and style name as well.

Created attachment 41881 [details]
advance-values-of-probably-buggy-fonts

Output of the advance values of the problematic fonts ("Nimbus Mono
L", "Luxi Mono", and "FreeMono").

In case of "FreeMono", the problem is probably in fontconfig.
The advance widths are 600 for most glyphs in "FreeMono", except for
U+0300 - U+0344 where the advance width is 0. But these are combining
characters and it is probably correct that thay have an advance
with of 0. I guess fontconfig should ignore the advance width for
combining characters.

See also:

http://lists.gnu.org/archive/html/freefont-bugs/2003-08/msg00000.html
http://lists.gnu.org/archive/html/freefont-bugs/2003-09/msg00001.html
http://lists.gnu.org/archive/html/freefont-bugs/2003-09/msg00002.html

I asked on the fontconfig mailing list about the "FreeMono" problem,
because I think in that case it is a fontconfig bug:

http://lists.freedesktop.org/archives/fontconfig/2005-July/001376.html

In case of "Luxi Mono", it appears to be a font bug.
Most glyphs in "Luxi Mono:style=Bold Oblique" have the advance
width 1229 but some differ. For example:

family=Luxi Mono style=Bold Oblique ucs4=326 glyph=175 advance=682

This is a combining character, probably it should have advance=0, certainly
not 628.

family=Luxi Mono style=Bold Oblique ucs4=201a glyph=c4 advance=1338

This is just a regular character, apparently it is designed too wide.
Compare with U+2019, it is quite obvious that it is just designed to
wide.

Same problem with "Nimbus Mono L", some characters are designed too
wide.

For "Nimbus Mono L", this could be fixed but it is difficult because
some glyphs need to be redesigned.

    [...]
    The Font Software may not be modified, altered, or added to, and in
    particular the designs of glyphs or characters in the Fonts may not
    be modified nor may additional glyphs or characters be added to the
    Fonts. This License becomes null and void when the Fonts or Font
    Software have been modified.
    [...]

The quote from a license in the last comment was from the license of
the Luxi fonts, i.e. the problem cannot be fixed in the Luxi fonts.

"Nimbus Mono L" has a free license and in theory the problem could be
fixed although fixing this in "Nimbus Mono L" would be a lot of work.

Created attachment 42982 [details]
improve-monospace-detection.patch

Patch to force the detection of "FreeMono", "Luxi Mono" and "Nimbus Mono L"
as monospaced.

With the patch from comment #16, "FreeMono" is recognized because with
that patch, all glyphs with an advance width = 0 are ignored in
checking whether a font is monospaced.

As "Luxi Mono" and "Nimbus Mono L" really contain a few glyphs which
are designed too wide, this doesn't help for these fonts.  Therefore I
added an exception for these two (broken) font families in fontconfig
to force them to be recognized as monospaced nevertheless.

It works fine and these two font families become selectable in konsole
and other KDE font dialogs which expect monospaced fonts at last.

I also solves the problem that mlterm always used the bold version of
"Luxi Mono" although the regular version was specified in the config
file.

Created attachment 42986 [details]
luxi-mono-konsole-overlap-problem.png

screen shot of konsole using "Luxi Mono:style=Bold Oblique".

This shows that glyphs may overlap when "Luxi Mono:style=Bold Oblique"
is used as a monospaced font.

For example, ‰ (U+2030) is designed too wide in "Luxi Mono:style=Bold
Oblique", in the screen shot parts of that glyph are hidden by the
following glyph of 'a'.

As only a few, rarely used glyphs in the "Luxi Mono" and "Nimbus Mono
L" families are designed too wide, I think it is OK to force the
detection of these fonts as monospaced with my hack in comment
#16. They work just fine as monospaced fonts, only when using one of
these rare glyphs one may see some overlap.

At least as  temporary workaround this is much better than nothing.

"Luxi Mono" cannot be fixed anyway. If somebody takes the time to fix
"Nimbus Mono L", I will remove this workaround for "Nimbus Mono L".

Packages with my workaround submitted to STABLE:

-------------------------------------------------------------------
Thu Jul 21 17:31:09 CEST 2005 - mfabian@suse.de

- update to 2.3.2.20050721.
- Bugzilla #52167: "fc-list reports inconsistent spacing values
  for some fonts": add a patch to improve the detection of
  monospaced fonts: ignore glyphs with advance=0 when detecting
  monospaced fonts and add a special exception for "Luxi Mono"
  and "Nimbus Mono L". 

-------------------------------------------------------------------

9.3 packages for testing here:

ftp://ftp.suse.com/pub/projects/m17n/9.3/i586/fontconfig-2.3.2.20050721-1.1.i586.rpm
ftp://ftp.suse.com/pub/projects/m17n/9.3/i586/fontconfig-devel-2.3.2.20050721-1.1.i586.rpm
ftp://ftp.suse.com/pub/projects/m17n/9.3/src/fontconfig-2.3.2.20050721-1.1.src.rpm
ftp://ftp.suse.com/pub/projects/m17n/9.3/x86_64/fontconfig-2.3.2.20050721-1.1.x86_64.rpm
ftp://ftp.suse.com/pub/projects/m17n/9.3/x86_64/fontconfig-devel-2.3.2.20050721-1.1.x86_64.rpm

Closing as FIXED.

Move product from SUSE Linux 10.1 → openSUSE 10.3 to make the bug public.

I have removed the patch to force monospace detection of “Luxi Mono” 
and “Nimbus Mono L”from the c-code now and added code to
/etc/fonts/suse-pre-user.conf which achieves the same.

This is easier to maintain.

Doing this in the setup files instead of in the c-code has
become possible only in recent versions of fontconfig.

 <match target="scan" >
  <test compare="contains" name="family" >
   <string>Luxi Mono</string>
   <string>Nimbus Mono L</string>
  </test>
  <edit mode="assign_replace" name="spacing">
   <const>mono</const>
  </edit>
 </match>