Summary: | unable to display bitmap-only (SFNT) TrueType or OpenType | ||
---|---|---|---|
Product: | fontconfig | Reporter: | Qianqian Fang <fangqq> |
Component: | library | Assignee: | Keith Packard <keithp> |
Status: | RESOLVED FIXED | QA Contact: | Behdad Esfahbod <freedesktop> |
Severity: | normal | ||
Priority: | medium | CC: | akira, freedesktop, hramrach, mozbugbox |
Version: | 2.6 | ||
Hardware: | x86 (IA32) | ||
OS: | Linux (All) | ||
URL: | http://fontforge.sourceforge.net/bitmaponlysfnt.html | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
fix ttf sfnt bitmap font charset count
Avoid blank glyphs interfere with sfnt bitmap font |
Description
Qianqian Fang
2009-08-15 18:02:16 UTC
I can see that fontconfig only sees three characters in that font. Will look into it later. The 4 characters are the blank chars: 0x20, 0xa0,0xad,0x3000. Well, 0xad is the soft hyphen. In the file fccharset.c, FcFreeTypeCharSetAndSpacingForSize() uses FcFreeTypeCheckGlyph() to test if a glyph is void or not. FcFreeTypeCheckGlyph() treats all the non-bitmap *blank* chars as non-void. Therefore FcFreeTypeCharSetAndSpacingForSize() would always have some valid characters for non-symbol fonts, even for empty fonts. Maybe FcFreeTypeCharSetAndSpacingForSize() should keep track of non-blank valid glyphs and return null when all the glyphs are blank. Or functions that calls FcFreeTypeCharSetAndSpacingForSize(), like FcFreeTypeCharSetAndSpacing() should check twice for the existance of non-blank glyph. I don't know if there are fonts whose sole purpose is to set the width of some blank chars... Mind attaching a font showing the problem? it is linked in the original report: http://wenq.org/release/wqy-bsong-0.9.9.NB.ttf.gz Created attachment 32612 [details] [review] fix ttf sfnt bitmap font charset count A few things addressed by the patch: 1. glyph load flag to load bitmap if strike_index specified. 2. keep track of glyph is not blank(space) characters. If a empty font found, return an empty charset (simply return 0 will trigger some segfaults with FcCharSet routines.) 3. FT_FACE_FLAG_SCALABLE is also set by freetype for bitmap only font, so don't rely on it. A not very related problem with FcCharSet. Since FcFreeTypeCharSetAndSpacingForSize() could return NULL, so any functions that deal with FcCharSet should consider a nullable arguement, like FcCharSetDestry(), FcCharSetCount(). Otherwise, you got segfaults on it. I did get quite some segfaults while debugging this bug. beautiful! thank you very much. Behdad, can you review this patch? I'm a bit late with my comment, but anyways...
> 3. FT_FACE_FLAG_SCALABLE is also set by freetype for bitmap only font,
> so don't rely on it.
Please explain. The font mentioned above *has* outline glyphs! This is *not* a bitmap-only font!
For testing purposes I've received a real SFNT bitmap-only font (with an empty `glyf' table) some time ago, and for such fonts FreeType correctly sets FT_FACE_FLAG_SCALABLE to FALSE.
(In reply to comment #7) > Please explain. The font mentioned above *has* outline glyphs! This is *not* > a bitmap-only font! You are right of course. The sample font has a single .notdef glyph in it which is auto-generated by fontforge when converting a bitmap font to ttf. Seems a known "feature" of fontforge: http://www.mail-archive.com/fonts@xfree86.org/msg01048.html However, the bug still exists for 'pure' bitmap-only font. I tested the sample font with the .notdef removed. Could you test the bug with your SFNT bitmap only font too? fc-list -v "fontname.ttf" and see the output of the Charset field. About the patch. Since the .notdef will always be added by fontforge to all the bitmap->TTF by default, I think ignoring the FT_FACE_FLAG_SCALABLE flag is the right thing to do. Sorry for the late reply. I've somehow missed your last comment. For the testfile Ambrosia.otb, which you can get from http://www.mail-archive.com/freetype-devel@nongnu.org/msg01055.html `fc-list -v Ambrosia' correctly shows scalable: FcFalse(s) but pango-view seems not be able to display it. And I like the idea of ignoring the .notdef glyph in specifying the SCALABLE flag within FreeType, so please provide a patch. (In reply to comment #9) > > And I like the idea of ignoring the .notdef glyph in specifying the SCALABLE > flag within FreeType, so please provide a patch. I have no idea how to do that. The internal drivers for sfnt, cff and truetype are myth to me. :( Then please file a bug report for FreeType so that this issue isn't forgotten. Created attachment 49753 [details] [review] Avoid blank glyphs interfere with sfnt bitmap font This patch forced sfnt bitmap font to be tested with a strike_index, therefore avoid the blank glyphs in the font to interfere with sfnt bitmap font. Just for completeness: Since version 2.4.6, FreeType no longer sets the FT_FACE_FLAG_SCALABLE flag for SFNT bitmap fonts which contain an outline glyph for `.notdef' only. Thanks for the patch. fixed in 1f01c4b6. (In reply to comment #5) > A not very related problem with FcCharSet. Since > FcFreeTypeCharSetAndSpacingForSize() could return NULL, so any functions that > deal with FcCharSet should consider a nullable arguement, like > FcCharSetDestry(), FcCharSetCount(). Otherwise, you got segfaults on it. I did > get quite some segfaults while debugging this bug. That should be somewhat better now. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.