Bug 23336 - unable to display bitmap-only (SFNT) TrueType or OpenType
Summary: unable to display bitmap-only (SFNT) TrueType or OpenType
Status: RESOLVED FIXED
Alias: None
Product: fontconfig
Classification: Unclassified
Component: library (show other bugs)
Version: 2.6
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Keith Packard
QA Contact: Behdad Esfahbod
URL: http://fontforge.sourceforge.net/bitm...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-15 18:02 UTC by Qianqian Fang
Modified: 2012-03-07 00:59 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments
fix ttf sfnt bitmap font charset count (3.02 KB, patch)
2010-01-13 04:23 UTC, Bug Fly
Details | Splinter Review
Avoid blank glyphs interfere with sfnt bitmap font (1.68 KB, patch)
2011-07-30 20:09 UTC, Bug Fly
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Qianqian Fang 2009-08-15 18:02:16 UTC
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
Comment 1 Behdad Esfahbod 2009-08-26 10:56:03 UTC
I can see that fontconfig only sees three characters in that font.  Will look into it later.
Comment 2 Bug Fly 2010-01-02 20:22:45 UTC
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...
Comment 3 Behdad Esfahbod 2010-01-06 16:43:34 UTC
Mind attaching a font showing the problem?
Comment 4 Qianqian Fang 2010-01-06 17:06:47 UTC
it is linked in the original report: 

http://wenq.org/release/wqy-bsong-0.9.9.NB.ttf.gz
Comment 5 Bug Fly 2010-01-13 04:23:56 UTC
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.
Comment 6 Qianqian Fang 2010-01-13 07:31:53 UTC
beautiful! thank you very much.
Behdad, can you review this patch?
Comment 7 Werner Lemberg 2011-04-19 13:24:41 UTC
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.
Comment 8 Bug Fly 2011-04-20 04:56:51 UTC
(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.
Comment 9 Werner Lemberg 2011-05-05 07:22:08 UTC
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.
Comment 10 Bug Fly 2011-05-05 09:14:36 UTC
(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. :(
Comment 11 Werner Lemberg 2011-05-05 20:20:29 UTC
Then please file a bug report for FreeType so that this issue isn't forgotten.
Comment 12 Bug Fly 2011-07-30 20:09:10 UTC
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.
Comment 13 Werner Lemberg 2012-03-06 22:27:29 UTC
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.
Comment 14 Akira TAGOH 2012-03-07 00:59:38 UTC
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.