30562 2009-10-20 04:16:50 -0700 [GTK] fast/text/zero-width-characters.html fails in GTK+ 2010-11-04 17:44:14 -0700 1 1 1 Unclassified WebKit Text 528+ (Nightly build) PC OS X 10.5 RESOLVED FIXED P2 Normal --- 1 xan.lopez webkit-unassigned hyatt mitz mrobinson oldest_to_newest 156125 0 xan.lopez 2009-10-20 04:16:50 -0700 From a brief investigation it seems our implementation fails to find the character used for the ZWS, so when latter all non-visible characters are rendered with its length they are rendered with non zero width. See WebCore/platform/graphics/GlyphPageTreeNode.cpp. 156883 1 xan.lopez 2009-10-22 07:57:13 -0700 OK, after looking at this a bit more: it seems what's happening is that our port reports glyph 0 as the one to be used for the character 0, ie (from SimpleFontData.cpp): Glyph zeroWidthSpaceGlyph = glyphPageZero->glyphDataForCharacter(0).glyph; zeroWidthSpaceGlyph will be 0. The next few lines prevent this from being used: if (zeroWidthSpaceGlyph) { if (zeroWidthSpaceGlyph != m_spaceGlyph) m_glyphToWidthMap.setWidthForGlyph(zeroWidthSpaceGlyph, 0); else LOG_ERROR("Font maps SPACE and ZERO WIDTH SPACE to the same glyph. Glyph width not overridden."); } So we never force the width of the ZWS to be 0, and later in the test 4 is used, which seems to be the width of the space glyph. If I remove the if (zeroWidthSpaceGlyph) check our test passes, so question: does the 0 glyph have any special significance? Is it a bug in our platform that we are returning it for the character 0? CCing hyatt and mitz since they were the ones last touching this code (2 years ago!). 156904 2 mitz 2009-10-22 09:28:33 -0700 0 indicates the missing glyph, so it appears that the font doesn’t have a glyph for ZWS. The code is written to avoid overriding the width of the missing glyph. 156905 3 xan.lopez 2009-10-22 09:31:01 -0700 (In reply to comment #2) > 0 indicates the missing glyph, so it appears that the font doesn’t have a glyph > for ZWS. The code is written to avoid overriding the width of the missing > glyph. Shouldn't we still somehow force width 0 even if the font lacks a glyph for those characters? 157659 4 mitz 2009-10-25 19:20:59 -0700 (In reply to comment #3) > (In reply to comment #2) > > 0 indicates the missing glyph, so it appears that the font doesn’t have a glyph > > for ZWS. The code is written to avoid overriding the width of the missing > > glyph. > > Shouldn't we still somehow force width 0 even if the font lacks a glyph for > those characters? If the font lacks a glyph for ZWS, then the next font from the font-family list will be used as fallback, and eventually the system fallback font will be used. Is it really the case that not even the system fallback font has a glyph for ZWS, or is there some other bug? If it’s the former, then maybe the fix should be targeted at the system fallback font case only somehow. 305048 5 mrobinson 2010-11-04 17:44:14 -0700 This seems to be passing after http://trac.webkit.org/changeset/70688 , so I will unskip this test.