On Linux, a per-script font setting may be a generic font like "serif" to allow fontconfig to choose a font depending on the script. So, we need to pass the language information down to fontconfig. However, currently in FontCache::createFontPlatformData we use Skia SkTypeface::CreateFromName to choose the font, which only accepts the font name and style (normal, bold, italic) which it then passes to fontconfig. I think we have two choices for a solution: 1. Modify Skia to accept language 2. Use fontconfig directly to get a font name, then pass that to Skia. WebKit bug 55453 is related, but I'm not sure exactly how. I guess it is for font-fallback when the attempted fonts don't cover the character to render, so it occurs at a later stage when necessary. It also seems there are related bugs on the Chromium tracker like http://crbug.com/31232 Also, the following comment on a Skia issue seems to mention the possibility of adding language support: http://code.google.com/p/skia/issues/detail?id=266#c1
My preference is to do #2 (which is similar to what Firefox does). Skia seems to be too low a level to deal with this issue. It's unfortunate that fontconfig works in terms of language rather than script code. So, we have to map scriptcode back to language (which is not 1:1).
Hm, I see. I thought option #1 could be good since Skia calls fontconfig anyway, so it seems we would hit fontconfig twice in #2. But I'll give #2 a shot and we can see if it has bad performance.
Cc'd reed just in case of #1. For #2, I'm not sure but https://bugs.webkit.org/show_bug.cgi?id=38701 might be related.
Thanks. There's an interesting idea in comment 21 https://bugs.webkit.org/show_bug.cgi?id=38701#c21 to get the filename from fontconfig so we can avoid the double use of fontconfig.
Another alternative is to pre-populate WebPreferences from fontconfig in advance (perhaps at the start-up time) if it's set to '<default>' (or generic font name like sans) instead of actual concrete font family). This will increase the start-up time, but we don't have to worry about hitting fontconfig twice during actual layout. If we do that, this has to be done in Chrome and it's not a webkit bug any more.