Summary: | CSS 2.1 tests are too dependent on machine fonts | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Alexey Proskuryakov <ap> | ||||
Component: | Tools / Tests | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | NEW --- | ||||||
Severity: | Normal | CC: | bdakin, cryo, ian, mitz | ||||
Priority: | P2 | ||||||
Version: | 420+ | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
Bug Depends on: | 6530 | ||||||
Bug Blocks: | 6524 | ||||||
Attachments: |
|
Description
Alexey Proskuryakov
2006-01-06 14:03:01 PST
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. fast/parser/entities-in-xhtml.xhtml also has this issue 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.
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.
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. *** Bug 8559 has been marked as a duplicate of this bug. *** *** 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> |