GNOME Bugzilla – Bug 73147
Add way to access glyph at index zero (unknown glyph) in fonts
Last modified: 2006-02-05 03:09:41 UTC
PangoXft, FT2 use glyph index 0 to mean a empty, zero-width glyph, which leaves no way to get to the actual "unknown glyph" for the font. Not too important since we draw our own unknown glyph representation for PangoXft and probably will for Xft eventually. (See discussion in bug 71931)
Shouldn't the FT2 backend draw an unknown glyph as well? At the moment it simply draws nothing but I think it should draw a rectangle instead (or actually the glyph provided by Freetype).
It would be best to be doing the same hex square drawing as the Xft, backend, I would say.
We have hex-box drawing for Xft. Bug 313551 is about adding that for cairo backend and this is for FT2. Some abstraction may not be out of place.
Actually, what this bug is about is getting access to the *real* unknown glyph (glyph index 0) in the font.
Ah, sorry. Was distracted by comments. BTW, am I right thinking that some systems (OS X?) use the U+FFFD REPLACEMENT CHARACTER for that purpose? The black diamond thing with a question mark in it.
Ok, I think I'm going to change this sometime soon and use (guint32)-1 for what currently glyphs==0 means. Any objections? I don't think the modules/backends developed outside pango are so many that this makes any real problem.
2006-02-02 Behdad Esfahbod <behdad@gnome.org> * modules/arabic/arabic-fc.c, modules/basic/basic-atsui.c, modules/basic/basic-fc.c, modules/basic/basic-win32.c, modules/basic/basic-x.c, modules/hangul/hangul-fc.c, modules/hebrew/hebrew-fc.c, modules/indic/indic-fc.c, modules/khmer/khmer-fc.c, modules/syriac/syriac-fc.c, modules/thai/thai-fc.c, modules/tibetan/tibetan-fc.c, pango/fonts.c, pango/pango-engine-private.h pango/pango-types.h, pango/pangocairo-fcfont.c, pango/pangocairo-font.c, pango/pangocairo-private.h, pango/pangocairo-render.c, pango/pangofc-decoder.c, pango/pangofc-font.c, pango/pangoft2-render.c, pango/pangoft2.c pango/pangowin32.c, pango/pangox.c, pango/pangoxft-font.c pango/pangoxft-private.h, pango/pangoxft-render.c, pango/shape.c: Use PANGO_GLYPH_NULL for when no glyph should be drawn. Use PANGO_GLYPH_UNKNOWN_FLAG for all backends to mark unknown flags. There's no need for pango_font_get_unknown_glyph() anymore, since all backends know how to handle PANGO_GLYPH_UNKNOWN_FLAG gracefully. We may add that in the future however. (fixes bug #73147, closes bug #329524)
Weird thing is that now that I fixed this, whatever font I have installed doesn't have glyph 0. Fontforge confirmed that.
I'm not sure that I'd consider using (guint)-1 instead of 0 to mean "dont' draw anything" is a compatible change. And also, glyph 0 to "no draw anything" is used in contexts other than missing glyphs ... for example, it's used in pango-layout.c:shape-tab. [glyph 0 is only a TrueType font convention, so doesn't apply to, say, the Fedora default font of Postscript Luxi Sans.]
Created attachment 58628 [details] [review] followup patch 2006-02-02 Behdad Esfahbod <behdad@gnome.org> Finish the 'glyph 0' work of this morning: PANGO_GLYPH_NULL that I introduced is renamed to PANGO_GLYPH_EMPTY. It means, no rendering should be performed. The backends however, still return 0 if a glyph is not found. The modules then are free to replace this 0 glyph with an unknown character. * modules/arabic/arabic-fc.c, modules/basic/basic-atsui.c, modules/basic/basic-fc.c, modules/basic/basic-win32.c, modules/basic/basic-x.c, modules/hangul/hangul-fc.c, modules/hebrew/hebrew-fc.c, modules/indic/indic-fc.c, modules/khmer/khmer-fc.c, modules/syriac/syriac-fc.c, modules/thai/thai-fc.c, modules/tibetan/tibetan-fc.c, pango/pangox.c, pango/pangowin32.c: Adapt to above change. Backends return 0 if glyph not found. * pango/fonts.c (pango_font_get_glyph_extents): If font is not usable (!PANGO_IS_FONT (font)), return the generic UNKNOWN_GLYPH metrics. This is used when your backends are misconfigured and you don't find *any* font at all. * pango/pango-engince.c: Add unknown glyphs in fallback shaper, instead of empty glyphs. * pango/shape.c: Call the fall-back shaper if shaper fails, instead of generating a dummy glyph string ourselves. * pango/pango-layout.c (imposed_shape, shape_tab): Use PANGO_GLYPH_EMPTY instead of glyph 0. * pango/pango-renderer.c (pango_renderer_draw_glyph): No-op on PANGO_GLYPH_EMPTY instead of glyph 0. * pango/pangocairo-atsuifont.c, pango/pangocairo-win32font.c, pango/pangocairo-fcfont.c, pango/pangocairo-font.c, pango/pangocairo-private.h: install_font returns a boolean now. * pango/pangocairo-render.c, pango/pangoxft-render.c: Handle font and hex-box failures more gracefully by drawing a generic unknown-box glyph. * pango/pangoft2.c, pango/pangoft2-render.c: Draw the generic unknown-box glyph here too. For unknown glyphs though, if the font is TTF (FT_IS_SFNT), use the zero-indexed glyph, otherwise, draw a box of proper size.
Owen, I believe this series of changes fixes this bug completely... So, looking now, what has changed is: to get a "draw nothing", you should use PANGO_GLYPH_EMPTY (which is just (PangoGlyph)-1), and you can ask any backend to draw an unknown glyph by using wc|PANGO_GLYPH_UNKNOWN_FLAG (which is 0x10000000). The fact that this two numbers share the high bit annoys me a bit. And that's going to be exposed to the wild, so we better decide now. Should I use 0x01000000 for PANGO_GLYPH_EMPTY? Other than that, it is a incompatible change, because previously modules were using 0 to mean "draw nothing", but 0 will draw the unknown glyph now... Should I increase the module interface version? The FT2 backend now uses the glyph 0 of TrueType fonts for unknown glyph, and draws a box for others... As for pango-layout.c and other places, they have all been updated to use PANGO_GLYPH_EMPTY of course.
Humm, second try.