[Fontconfig] Mozilla, Xft and (buggy?) fonts

Anthony Fok fontconfig@fontconfig.org
Wed, 12 Feb 2003 02:39:09 +0800


I was trying to track down an issue we have with Mozilla Xft with a certain
font.  A screenshot is here:


I have checked the font with Microsoft Font Validator etc., and it seems
that the font itself is okay.

There appears to be two issues:

 1. The font in question contains no glyph for U+00A9 "(c)" copyright
    sign, and there was no such mapping in the CMap 4 table.  However,
    there is a CMap Format 0 (language=0) MacRoman table, in which 0xA9
    is mapped to "Lambda" (glyph #170 in that font).  So, it appears
    that fc-cache read in both the Unicode (CMap4) and MacRoman (CMap0)
    tables and added U+00A9 -> Lambda.

    To test this theory, I used TTX/fontTools to get rid of the
    cmap_format_0 section altogether.  Now, the (c) sign is properly
    displayed, obtained from another font.

    Would it be a good idea, if a font already contains a valid
    Unicode CMap (e.g. Format 4 and/or 12), that CMap 0 be ignored
    altogether?  There appears to be more buggy fonts out there on the
    market than we would like.  Anyhow, I have no preference either
    way, so, you make the call.  :-)

 2. Now, the scrambled text after the supposed "(c)"... this perplexes me.
    As shown in the screenshot, already cached glyphs are okay, but
    newly loaded ones are off:

	b -> |
	s -> multiple sign
	d -> ~
	P -> j
	R -> l
	f -> currency sign
	w -> e acute
	m -> A acute
	, -> F
	I -> c
	U -> o
	. -> H
	S -> m
	" " -> :
	G -> a
	O -> i
	V -> p
	E -> _
	R -> l

    A visual check with ftview showed that the glyph indices are off by 26

    I am a slow debugger.  :-)  So I traced from Mozilla's Xft
    interface to XftDrawCharFontSpec to XftCharIndex before the end of
    the day.  My next guess is whether the "U+00A9 -> Lambda glyph"
    could have triggered a hidden bug in Xft or in fontconfig in which
    the Unicode->glyph hash table got corrupted?

There are a few other Mozilla Xft issues as seen on Bugzilla.  The
"disappearing text when with switching fonts" happens on my Debian
sid/unstable system (XFree86 4.2.1, with XRender).  A fellow
Debian Chinese developer noticed the same thing.  On a similar Debian
system using i830 chipset (XFree86 4.2.1, without XRender), it crashes
instead.  However, everything looks and works okay on Red Hat 8.0
and Phoebe.  Not quite sure what the difference is.  Any idea?  :-)



Anthony Fok Tung-Ling
ThizLinux Laboratory   <anthony@thizlinux.com> http://www.thizlinux.com/
Debian Chinese Project <foka@debian.org>       http://www.debian.org/intl/zh/
Come visit Our Lady of Victory Camp!           http://www.olvc.ab.ca/