Hello Keith, On Tue, Feb 11, 2003 at 11:04:26AM -0800, Keith Packard wrote:> > A visual check with ftview showed that the glyph indices are off by 26 > > I have a vague recollection of having fixed a bug like this. Can you > report which versions of the X server, Xrender, Xft and fontconfig you are > using?It turns out that it was the font itself afterall. I finally got to FcFreeTypeCharIndex(), and added some printf''s in there. It turns out that: * Before the copyright sign: FT_ENCODING_UNICODE, all is fine. * At the copyright sign: got switched to FT_ENCODING_APPLE_ROMAN * After the Copyright Sign, all the text are still in the ASCII range, so FcFreeTypeCharIndex() stayed with FT_ENCODING_APPLE_ROMAN. Unfortunately, this font''s CMap Format 0 AppleRoman is all wrong: U+0006 got mapped to space (rather than U+0020), and similarly, everything else is off by the same amount. 0x20 - 0x6 = 0x1A = 26. That explains it. No wonder I couldn''t reproduce this problem with any other fonts. But I am glad that this is no bug of fontconfig/Xft afterall. :-) Oh, speaking of which, I have a patch for you to change "ft_encoding_*" to their uppercase equivalent. Please apply it as appropriate (unless you need to maintain compatibility with FreeType 2.0.x.) Cheers, Anthony -- 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/ -------------- next part -------------- --- fontconfig-2.1.orig/src/fcfreetype.c +++ fontconfig-2.1/src/fcfreetype.c @@ -345,7 +345,7 @@ /* * Convert AppleRoman to Utf8 */ - map = FcFreeTypeGetPrivateMap (ft_encoding_apple_roman); + map = FcFreeTypeGetPrivateMap (FT_ENCODING_APPLE_ROMAN); if (!map) continue; --- fontconfig-2.1.orig/src/fccharset.c +++ fontconfig-2.1/src/fccharset.c @@ -1642,9 +1642,9 @@ }; static const FcFontDecode fcFontDecoders[] = { - { ft_encoding_unicode, 0, (1 << 21) - 1 }, - { ft_encoding_symbol, &AdobeSymbol, (1 << 16) - 1 }, - { ft_encoding_apple_roman, &AppleRoman, (1 << 16) - 1 }, + { FT_ENCODING_UNICODE, 0, (1 << 21) - 1 }, + { FT_ENCODING_MS_SYMBOL, &AdobeSymbol, (1 << 16) - 1 }, + { FT_ENCODING_APPLE_ROMAN, &AppleRoman, (1 << 16) - 1 }, }; #define NUM_DECODE (sizeof (fcFontDecoders) / sizeof (fcFontDecoders[0]))
Hello Keith, Wow, immediate response again! I''m really amazed! Many thanks! :-) On Tue, Feb 11, 2003 at 11:04:26AM -0800, Keith Packard wrote:> > 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. :-) > > Fonts are also broken in the other direction -- they contain both Unicode > and Apple Roman mappings, but the Unicode mapping doesn''t map Latin glyphs > while the Apple Roman mapping cannot cover the glyphs available in the > font. Suggestions for how to figure out the right mapping are welcome...I didn''t know that. Yikes! Meanwhile, for my part, I have been exchanging e-mail messages with the respective font vendors asking them to fix these bugs. Fortunately, they have been quite responsive. Microsoft''s Font Validator has been helpful, and ftview, TTX/FontTools are lifesavers.> > A visual check with ftview showed that the glyph indices are off by 26 > > I have a vague recollection of having fixed a bug like this. Can you > report which versions of the X server, Xrender, Xft and fontconfig you are > using?On Debian unstable, XFree86-4.2.1; Xft-2.1, fontconfig-2.1, probably without updates from the CVS except: fontconfig (2.1-14) unstable; urgency=low * debian/patches/CVS-HEAD-subpixel-rendering-fix.patch: - New patch, should fix crashes when subpixel rendering is turned on (Closes: #175903). Big thanks to Michael Guntsche <mike@it-loops.com> for extracting the relevant fix from CVS! -- Colin Walters <walters@debian.org> Fri, 10 Jan 2003 13:30:28 -0500 BTW, how do I check the Xrender version? :-) (XFree86 says something about "XFree86 Font Renderer : 0.3". Is that the same thing? :-) By the way, where may I find the latest CVS of fontconfig and Xft? It seems that fontconfig in :pserver:anoncvs@keithp.com:/local/src/CVS isn''t the newest.> > 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). > > ... > > However, everything looks and works okay on Red Hat 8.0 and Phoebe. > > I suspect RH has incorporated various fixes from current XFree86 CVS which > haven''t made it into Debian unstable yet. Please give current CVS a try > and see what happens there.Good idea. I should try that. Thanks again for your help, Anthony -- 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/
Around 2 o''clock on Feb 12, Anthony Fok wrote:> 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. :-)Fonts are also broken in the other direction -- they contain both Unicode and Apple Roman mappings, but the Unicode mapping doesn''t map Latin glyphs while the Apple Roman mapping cannot cover the glyphs available in the font. Suggestions for how to figure out the right mapping are welcome...> A visual check with ftview showed that the glyph indices are off by 26I have a vague recollection of having fixed a bug like this. Can you report which versions of the X server, Xrender, Xft and fontconfig you are using?> 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). > ... > However, everything looks and works okay on Red Hat 8.0 and Phoebe.I suspect RH has incorporated various fixes from current XFree86 CVS which haven''t made it into Debian unstable yet. Please give current CVS a try and see what happens there. Keith Packard Cambridge Research Lab Hewlett Packard
Hello,
I was trying to track down an issue we have with Mozilla Xft with a certain
font. A screenshot is here:
http://anthony.homelinux.net/~foka/xft/Mozilla-Xft-font-issue.png
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
etc.
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? :-)
Cheers,
Anthony
--
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/