GNOME Bugzilla – Bug 71931
Pango renders glyphs for some zero-width chars
Last modified: 2004-12-22 21:47:04 UTC
All basic shaper modules have code to suppress rendering of zero-width characters. For the different modules these are at the moment: basic-ft2 and basic-x: ZERO WIDTH SPACE (200B) LEFT-TO-RIGHT MARK (200E) RIGHT-TO-LEFT MARK (200F) basic-xft: ZERO WIDTH SPACE (200B) ZERO WIDTH NON-JOINER (200C) ZERO WIDTH JOINER (200D) LEFT-TO-RIGHT MARK (200E) RIGHT-TO-LEFT MARK (200F) This set of characters is however not complete. It should be unified and extended to also hold the formatting characters LEFT-TO-RIGHT EMBEDDING (202A) RIGHT-TO-LEFT EMBEDDING (202B) POP DIRECTIONAL FORMATTING (202C) LEFT-TO-RIGHT OVERRIDE (202D) RIGHT-TO-LEFT OVERRIDE (202E) I've noticed this particular problem when rendering text originating from Yudit which generates LRO, RLO and PDF chars when editing arabic. Some fonts (Arial) seem to have glyphs for this chars but I don't think it is desired to actually render something for these formatting chars. I'll attach a patch to all three basic shapers that addresses this problem.
Created attachment 6774 [details] [review] Patch to unify and extend the list of zero-width chars in all basic shaper modules
Sat Feb 23 17:34:26 2002 Owen Taylor <otaylor@redhat.com> * modules/basic/basic-{ft2,x,xft}.c: Patch from Sven Neumann to extend and make consistent the set of zero-width characters that are not displayed. (#71931)
I checked the CVS last night and it only changed the glyph for all zero width characters to glyph num 0, but it does not explicitly set the glyph width to zero. May I commit to CVS a fix that forces the width of all the zero width characters in the basic modules to be zero?
Created attachment 6841 [details] [review] Patch to force width of zero width characters to zero.
I added a patch that solves the problem of the zero width characters. Ok to commit?
At least the X and FT2 backends both handle glyph 0 specially and assign empty logical and ink rectangles. The change Dov suggested is thus not needed for basic-x.c and basic-ft2.c. I'm not sure about the Xft backend however. pango_xft_font_get_glyph_extents() calls XftTextExtents32 () with the 0 glyph to determine the extents. If this function really returns non-zero extents for the glyph 0, the Xft backend might need the fix. Dov, have you ever observed any rendering problems that could be caused by the problem your patch tries to fix? I strongly doubt there's a problem at all...
It should be pointed out that glyph 0 is supposed to always be present in TrueType fonts, and is the "unknown glyph" glyph. We don't actually use this in the Xft backend and draw our own fancy unknown glyphs instead, but if we want to adopt the x backend idea that 0 represents an empty glyph (and I think this makes some sense the way Pango works, you really need empty glyphs for unrendered characters), then we have to do so formally. I think making the convention that: 0 is the empty glyph pango_ft2_get_unknown_glyph (font), pango_xft_get_unknown_glyph (font, 0); are the TT unknown glyph glyph. Would probably work fine.
Fri Mar 1 14:37:47 2002 Owen Taylor <otaylor@redhat.com> * pango/pangoxft-font.c (pango_xft_font_get_glyph_extents): Treat glyph 0 as an 0 size, non-drawn glyph consistent with other backends. (#71931) Bug 73147 covers issue of getting to the actual unknown glyph