Comment 115 for bug 1468027

Not sure. Some fontconfig tracing env vars might be useful for the Skia LegacyCreateTypeface part I guess...

* * *

In addition to the weight matching problem, the screenshot for Chromium in #113 gives the JP variant instead of TW. Perhaps I should try to get someone to reproduce this in other distros and file a report upstream... Not sure about what the title will be.

> Don't Chrome and Chromium care about fontconfig, but do it their own way?

Chrome seems to provide some level of per-script font handling[1]. Actually Google Chrome gives a link to an extension called ‘Advanced Font Settings’ (caclkomlalccbpcdllchkeecicepbmbm) in its font menu...

  [1]: https://developer.chrome.com/extensions/fontSettings

Regarding the JP problem, it seems that Google Chrome is trying to do the script recognition itself. This happens on my Windows 10 machine too -- Chinese comments on GitHub and Tweets are all rendered using ‘Inziu Roboto JP’, my default Japanese script font set with ‘Advanced Font Settings’. Webpages with explicit language/script declarations like https://zh.wikipedia.org/zh-tw/ work fine since they don't need any recognition by Chrome (will anyone confirm this on Ubuntu?)

It seems that some Chrome font settings can be pre-hacked by editing webkit.webprefs.fonts. The 'Zyyy' (default script) one found in chrome settings is stored in the file 'Preferences' -- perhaps some settings for other scripts can be filled in here too?