Bug 30562 – [GTK] fast/text/zero-width-characters.html fails in GTK+

• Component: Text
• Status: RESOLVED FIXED

[Xan Lopez]

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.

[Xan Lopez]

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!).

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.

[Xan Lopez]

(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?

(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.

[Martin Robinson]

This seems to be passing after http://trac.webkit.org/changeset/70688 , so I will unskip this test.