Bugzilla – Bug 52167
fc-list reports inconsistent spacing values for some fonts.
Last modified: 2007-02-20 17:00:05 UTC
For some fonts which are supposed to be monospaced fonts, fc-list neither reports spacing=100 nor spacing=110 but no spacing at all (which means proportional).
<!-- 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>