Bug 30562 - [GTK] fast/text/zero-width-characters.html fails in GTK+
Summary: [GTK] fast/text/zero-width-characters.html fails in GTK+
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-10-20 04:16 PDT by Xan Lopez
Modified: 2010-11-04 17:44 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Xan Lopez 2009-10-20 04:16:50 PDT
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.
Comment 1 Xan Lopez 2009-10-22 07:57:13 PDT
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!).
Comment 2 mitz 2009-10-22 09:28:33 PDT
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.
Comment 3 Xan Lopez 2009-10-22 09:31:01 PDT
(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?
Comment 4 mitz 2009-10-25 19:20:59 PDT
(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.
Comment 5 Martin Robinson 2010-11-04 17:44:14 PDT
This seems to be passing after http://trac.webkit.org/changeset/70688 , so I will unskip this test.