Our getLastResortFallbackFont is a stub. We should fall back on the generic names "Sans", "Serif", etc. if our other fallbacks have failed. (Note that we intentionally *don't* map CSS names like "sans-serif" via the settings because we want those to remain Arial for compatibility.) See also http://code.google.com/p/chromium/issues/detail?id=10665
Created attachment 30456 [details] fix WebCore/ChangeLog | 11 +++++++++ .../platform/graphics/chromium/FontCacheLinux.cpp | 24 ++++++++++++++++++- 2 files changed, 33 insertions(+), 2 deletions(-)
Adding some reviewers for comments.
I have no way of knowing if this font fallback behavior is "correct" or not. Hyatt might know. This looks different from the Mac code, but maybe is correct for Chromium? Seems a little silly to fallback to Sans twice.
Yes, in the Mac code it uses this strictly for last resort fallback. However this behavior more closely matches FontCacheChromiumWin. I also don't know which is more correct. Note that I *believe* that keeping "sans-serif" in CSS matching "Arial" in font lookup is desirable.
Oh, and the double-fallback is a bit silly, but the alternatives are all more code. And a system that doesn't have "Serif" or "Monospace" set up is pretty seriously broken. One idea is just to remove that last try, because if you don't have those fonts you're unlikely to have Sans anyway. I'd still want to add a "default:" on the switch then.
Comment on attachment 30456 [details] fix Hyatt's AWOL, or at least not answering mail. This ain't gonna hurt anything and seems sane enough for Linux.
Created attachment 30565 [details] fix WebCore/ChangeLog | 11 ++++++++++ .../platform/graphics/chromium/FontCacheLinux.cpp | 21 ++++++++++++++++++- 2 files changed, 30 insertions(+), 2 deletions(-)
Created attachment 30566 [details] align with switch WebCore/ChangeLog | 11 ++++++++++ .../platform/graphics/chromium/FontCacheLinux.cpp | 21 ++++++++++++++++++- 2 files changed, 30 insertions(+), 2 deletions(-)
Comment on attachment 30566 [details] align with switch Looks great. Dave could add an ASSERT(fontPlatformData); right before the return. In that case, where a user's system is totally hosed, we might as well crash early instead of late.
http://trac.webkit.org/changeset/44015