Bug 6400 – CSS 2.1 tests are too dependent on machine fonts

• Status: NEW
• Component: Tools / Tests

[Alexey Proskuryakov]

Some CSS 2.1 tests use fancy characters that aren't present in Times font. Depending on which fonts 
are installed on the machine, different results are generated.

Unless it's possible to somehow control font fallback in DRT, we may need to replace the characters 
with something less fancy. Hixie said: "if you can make an exact list of which tests suffer from this 
problem, and if you can provide a list of cute glyphs that don't suffer from this problem, then mail the 
[e-mail] list".

Tests currently known to be affected:
css2.1/t0905-c414-flt-00-d.html
css2.1/t0805-c5519-brdr-r-01-e.html
css2.1/t0905-c5525-fltblck-00-d-ag.html

[Alexey Proskuryakov]

WebTextRenderer uses SPIs to find substitute fonts (WKGetFontInLanguageForRange(), 
WKGetFontInLanguageForCharacter()). ATSUI has an explicit way to control font fallback <http://
developer.apple.com/documentation/Carbon/Conceptual/ATSUI_Concepts/atsui_chap6/
chapter_6_section_2.html>; don't know about AppKit SPIs.

There appear to be several possible solutions:
1) Just modify the tests, so that font fallback isn't needed.
2) Find an appropriate AppKit SPI or rewrite WKGetFontInLanguageFor...() using ATSUI, giving a 
predefined list of allowed fallback fonts when running in DRT.
3) Make findSubstituteFont() try common Apple fonts after the CSS family fallback list, but before the 
system-provided fallback when running in DRT.

[Alexey Proskuryakov]

fast/parser/entities-in-xhtml.xhtml also has this issue

[Alexey Proskuryakov]

Created attachment 5574 [details]
proposed fix

Apparently, it's not possible to match AppKit font fallback with a simple list,
but only a few results changed with such an implementation, so it might
actually be OK:

fast/block/positioning/047.html - results changed inconsequentially
fast/xsl/xslt-text.xml - results changed inconsequentially
css2.1/t0905-c5525-fltblck-00-d-ag.html - results were incorrect (taken with
Arial Unicode MS; correct results didn't change)
css2.1/t0805-c5519-brdr-r-01-e.html - results were incorrect (taken with Arial
Unicode MS; correct results didn't change)
svg/W3C-SVG-1.1/text-fonts-01-t.svg - results were and still are
machine-dependent (because CSS styles have fonts that are not present on all
machines)
svg/W3C-SVG-1.1/text-intro-01-t.svg - ditto
svg/W3C-SVG-1.1/text-intro-02-b.svg - ditto
svg/W3C-SVG-1.1/text-intro-03-b.svg - ditto
svg/W3C-SVG-1.1/text-intro-04-t.svg - ditto

There is a rather strange problem with WebTextRendererFactory - it wouldn't see
that Monaco is a fixed pitch font. Furthermore, a similar problem apparently
exists for Osaka-Mono, but I couldn't  understand how (and if) the workaround
for it works, so I had to add some slightly different code.

[Darin Adler]

Comment on attachment 5574 [details]
proposed fix

I like the idea of altering the fallback behavior to behave in a fixed way
during the layout tests.

But this does prevent us from doing any testing of the font substitution
machinery in layout tests, so I'm a bit ambivalent about it.

I'd really like to see us have a consistent rule about fallback even outside
layout tests.

I think the Monaco fix should be handled separately.

[Alexey Proskuryakov]

Comment on attachment 5574 [details]
proposed fix

Removing the review flag to factor out the Monaco fix, and to consider fixing
bug 6524 along these lines.

[Alexey Proskuryakov]

*** Bug 8559 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

*** Bug 8560 has been marked as a duplicate of this bug. ***

This has been addressed for Windows using a per-directory prologue, a persistent user style sheet in DumpRenderTree and @font-face rules with unicode-range.
<http://trac.webkit.org/projects/webkit/changeset/29822>