[Webkit-unassigned] [Bug 20237] Zero width and space characters are displayed incorrectly if not contained in a fallback font.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=20237





------- Comment #19 from dglazkov at chromium.org  2008-09-08 10:35 PDT -------
Well, I dug some more, using a pristine (font-wise) XP install and here's what
happens for the ZWS chars for a standard Win font, using Times New Roman as an
example.

wkGetGlyphs returns 0 for the 0x200B char, so the glyph doesn't exist in the
font, but FontCache::getFontDataForCharacters is able to scare up the glyph
using font-linking (the glyph is borrowed from Lucida Sans Unicode).

In the case of 0xFFFC, the same path is followed, except no glyph is found
using font-linking, so we fall back into Uniscribe, drawing the string into a
metafile. Unlucky for us, this succeeds with (woot!) "Times New Roman", which
brings back the original font, which in turn draws a square in place of the
character.

So, the proposed patch, IMHO (I am not a fonts expert, please correct me if I
am wrong) eliminates the need to dip into the IMLang linking business and
avoids creating metafile objects for drawing the ORC char.

I don't have a strong opinion about moving the SimpleFontData substitution
logic to Font::glyphDataForCharacter. My thinking was to initialize the
FontCache with the substituted objects to begin with, so that there's no
additional checking while drawing each character.


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.