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 public-css-test@w3.org 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
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>