Chrome Version : 18.0.1025.142 OS Version: OS X 10.7.3 URLs (if applicable) : 1. http://zh.wikipedia.org 2. http://facebook.com Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5: OK What steps will reproduce the problem? 1. Open any page in Chinese e.g. Google Taiwan / HK / China 2. (There is no step 2) 3. What is the expected result? Chrome should use my system-wide font fallback What happens instead? Chrome decides which font it is going to use for fallback by language. Please provide any additional information below. Attach a screenshot if possible. No. This is not what we want. Since some version of Chrome beta, the Chrome decides the fallback font it is going to use by language, instead of the operating system's default fallback font. For example, you choose LiHei Pro for Traditional Chinese, and HeiTi SC for Simplified Chinese. But in some websites, these two dialects are both in use (e.g. Wikipedia). The language detection will cause inconsistency of Chinese fonts from page to page, even they're in the same website. What's worse, most beautiful Chinese fonts has *ugly* alphanumeric characters. The two fonts you chose for Trad. and Simp. Chinese - LiHei Pro and HeiTi TC -- both have really, really ugly latin characters. Before Chrome 18, I can see latin characters rendered in beautiful Helvetica. But now, I can only see those ugly letters from Chinese fonts. I don't use Firefox because FIrefox can only choose exactly one font for each of sans-serif, serif and monospace, which makes me upset when I see ugly latin characters. You are doing the same wrong thing as Firefox. Or even worse. I can see screen flashes when visiting a Wikipedia article that is mixed with Trad. and Simp. Chinese (zh.wikipedia.org). For example, if you visit http://zh.wikipedia.org/zh-cn/Google , you'll see that the fonts flashes between HeiTi TC (for Simp. Chinese) and LiHei Pro (for Trad. Chinese), and back and forth until the page is fully loaded. This is the worst user experience I have ever experienced. Please stop detecting the language of the page and deciding what font for fallback. It is inconsistent if I see a page rendered with HeiTi TC, and another page in LiHei Pro, where they're both in Chinese. Or just fallback to my OS X's default font fallback. I'm happy to see Hiragino Sans GB for all Kanji (including Chinese & Japanese) and Helvetica for Latin characters. Don't rape my eye. I have a screenshot attached with this issue. I opened the same URL: http://zh.wikipedia.org and select "台灣正體" (Taiwanese Traditional Chinese). Safari 5.1.5 on the left side, Chrome 18 on the right side. The reading experience are significantly different from Safari to Chrome. This time, Safari does the right thing, and Chrome is totally wrong. You should fix this bug as soon as possible, or you're probably losing Chinese users. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.142 Safari/535.19
Apr 2 2012,
Apr 3 2012,
Apr 3 2012,
Thanks for your feedback and sorry for your bad experience. This change is part of the work for supporting per-script/language fonts, which a sizable chunk of users seem to want (it's tracked at issue 2685 ). So I'm not sure I want to turn it off completely. Currently, Chrome has default fonts it chooses for certain languages, as you noticed, including Traditional Chinese and Simplified Chinese. Work is ongoing to provide a way to customize these fonts ( issue 2685 , issue 114805 ). Then you would be able to, for example, set your Chinese and Japanese fonts to Hiragino Sans GB. You could also set them to blank which would result in the system font-fallback behavior. By the way, there is an experimental extension API and a sample extension for this available on the dev channel: http://code.google.com/chrome/extensions/dev/experimental.fontSettings.html As for the ability to use a different font for Latin characters, even if the webpage content is labeled as Chinese, that will be more difficult. One possibility could be to allow a list of fonts like "Helvetica, Hiragino Sans GB" instead of a single font as the font preference. Or, setting the font preferences to blank would effectively stop the per-script font feature. I'll mark this as WontFix for now, since I don't think we'll stop per-script font support completely. Feel free to open new bugs for the font flashing issue and allowing a list of fonts for the per-script font preference (possibly at bugs.webkit.org, as it'd be a WebKit feature) if you'd like.
Apr 15 2012,
OK, I see. I downloaded Chrome Canary and installed the experimental extension. I can customize the fallback font as expected. I hope this feature being available on the release build in the near future.
Apr 18 2012,
Thanks for the update. Please feel free to provide more feedback about the extension or extension API if you have some. The more adoption/feedback of the experimental API, the easier it is to graduate from experimental.
May 3 2012,
Hi, I've made an extension with the experimental API to turn off Per-Script font as I wish. I know that the current Canary has a new version of API and my extension will not work on sooner or later, but I would like to let you know that some people like me wish we could still use system font fallback instead of a Chrome-determined algorithm. It would be better if we can turn off this feature with a single checkbox. https://github.com/chitsaou/no-per-script-font/blob/master/README-en.md I've also opened a new issue #126103 describing my thoughts on the "text flashing" and "wrong font displayed" issues.
May 3 2012,
Sorry for the late response. I've been on leave. Anyway, I stand by what falken wrote and appreciate you for your feedback and understanding.
May 9 2012,
Thanks for your feedback and the link to your extension! Your extension will make it easier to move the API out of experimental.
Jul 26 2012,
Just a heads up: the extension API has been moved out of experimental in M22 (the current dev channel). So unfortunately your extension will require some changes to work on M22. I think it should just be changing the permission string from 'experimental' to 'fontSettings' and renaming the 'fontName' property to 'fontId'.
Jul 26 2012,
Thanks! I'll take a look at the new API document.
Oct 13 2012, Project Member
This issue has been closed for some time. No one will pay attention to new comments. If you are seeing this bug or have new data, please click New Issue to start a new bug.
Mar 10 2013, Project Member
Apr 6 2013, Project Member
Apr 6 2013, Project Member
Sign in to add a comment