After changes in r101712[1] there are 67 tests loaded into fontconfig. Locally this causes plenty of font-related failures. If fonts in WebKitBuild/Dependencies/Root/webkitgtk-test-fonts are reduced down to only 18 files that were being loaded before r101712, the tests pass normally. I do not know how the bots did not pick up this misbehavior. One way of fixing this would be to distribute only the required 18 font files. [1] http://trac.webkit.org/changeset/101712/trunk/Tools/DumpRenderTree/gtk/DumpRenderTree.cpp
I think it's important that we understand why the results on your machine differ from the bots (and from my machine). It seems that that the additional fonts, just uncovered some other issue.
So, me and Martin were investigating this quite a lot on Saturday. At one point it seemed as fontconfig caches were to blame since the tests passed after I removed ~/.fontconfig/, but this seemed to be only a one-time-thing, because now even that does not help anymore. Anyhow, it seems that only tests with complex text are failing for me, and complex text being handled by Pango (AFAIK), I now firmly believe Pango is to blame. Lucky for me (if that's luck) I can reproduce these failures on two different Debian-based set-ups, Ubuntu 11.10 and Linux Mint 12. The problem is that DejaVuSansMono.ttf gets somehow loaded and then used for complex text, causing failures. Removing this font file fixes this, but this seems not to be required on set-ups by other developers. I'll look into Pango to see why exactly that font is loaded and how it can be avoided.
You might try the patch I've posted here: https://bugs.webkit.org/show_bug.cgi?id=73771 . It ensures that certain fonts are loaded during fallback.
(In reply to comment #3) > You might try the patch I've posted here: https://bugs.webkit.org/show_bug.cgi?id=73771 . It ensures that certain fonts are loaded during fallback. Nope, this patch does not resolve the issue.
Is this still an issue for you?