I brought this up previously in Fedora's font list [1]. After some further tests, I realized that SFNT bitmap-only ttf is still not supported by the main-stream Linux font rendering pipeline (freetype2/fontconfig/pango etc, I am not sure which one). About 3 years ago, with hand-coded cache file, this SFNT TTF font used to be OK. Then it stopped working because fontconfig stared to use a binary cache file and it does not recognize SFNT TTF [2]. Only recently, I recognized that fc-cache worked ok with this font, but still, the font can not be rendered. Here is a test. An SFNT TTF CJK font can be downloaded from here [3] (2.4M). It is produced by fontforge [4]. First, make sure you do not have wqy-bitmap-fonts or xfonts-wqy installed. Then unzip the file and install it to your ~/.fonts/ and update fc cache. Now, fc-list and fc-match are able to query the detailed info of the font (WenQuanYi Bitmap Song). It works up to this point. However, if you select this font from a font dialog, bitmap glyphs will never be displayed; instead, it will be displayed by the fall-back fonts (DejaVu etc). Same thing when running pango-view: pango-view --waterfall --font="WenQuanYi Bitmap Song" --text="文泉驿点阵宋体" Since PCF/BDF are becoming legacy formats and SFNT TTF seems to be the most promising alternative. It would be great to support them in the font rendering pipeline of modern desktop. (please let me know if this is an issue of freetype2 or else) [1] http://www.mail-archive.com/fedora-fonts-list@redhat.com/msg00847.html [2] http://lists.freedesktop.org/archives/fontconfig/2006-August/002365.html [3] http://wenq.org/release/wqy-bsong-0.9.9.NB.ttf.gz [4] http://fontforge.sourceforge.net/bitmaponlysfnt.html
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.