Bug 41599 – optimizeLegibility doesn't play nice with fonts that do not have a space glyph

• Component: Layout and Rendering
• Status: RESOLVED FIXED

when using "text-rendering: optimizeLegibility;" on a site with @font-face, webkit tends to clip-off part of the text.

Example:
http://www.fontsquirrel.com/fontfacedemo/Alpha-Echo
+ css:
html { text-rendering: optimizeLegibility; }

The problem appears to be this:

ERROR: Font maps SPACE and ZERO WIDTH SPACE to the same glyph. Glyph width will not be overridden.
(WebCore/platform/graphics/SimpleFontData.cpp:164 void WebCore::SimpleFontData::platformGlyphInit())

Further debugging shows that the problem is that the font doesn’t map the SPACE character to a glyph. WebKit substitutes the space glyph from the next font in fallback order, but in some code paths, WebKit uses the cached space width from the font itself, which is bogus. This discrepancy is what’s causing the incorrect line breaking.

Specifically, in RenderBlock::findNextLineBreak(), the initialization of wordTrailingSpaceWidth should probably be changed to measure a space character instead of using the cached space width.

Created attachment 60554 [details]
Account for font fallback in initializing wordTrailingSpaceWidth

Fixed in <http://trac.webkit.org/projects/webkit/changeset/62510>.

[WebKit Review Bot]

http://trac.webkit.org/changeset/62510 might have broken Leopard Intel Release (Tests)