New issue
Advanced search Search tips
Starred by 5 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Apr 2012
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

  • Only users with Commit permission may comment.

Sign in to add a comment

Issue 121461: Stop Language-specific Font Fallback, Please.

Reported by, Apr 2 2012

Issue description

Chrome Version       : 18.0.1025.142
OS Version: OS X 10.7.3
URLs (if applicable) :

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)

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

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 (  For example, if you visit , 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: 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
Screen Shot 2012-04-03 at 00.02.27.png
957 KB View Download

Comment 1 by, Apr 2 2012

Labels: -Area-Undefined Area-UI Feature-Fonts

Comment 2 by, Apr 3 2012


Comment 3 by, Apr 3 2012

Status: WontFix
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:

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, as it'd be a WebKit feature) if you'd like.

Comment 4 by, 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.

Comment 5 by, 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.

Comment 6 by, 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.

I've also opened a new  issue #126103  describing my thoughts on the "text flashing" and "wrong font displayed" issues.

Comment 7 by, 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.

Comment 8 by, 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.

Comment 9 by, 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'.

Comment 10 by, Jul 26 2012

Thanks! I'll take a look at the new API document.

Comment 11 by, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
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.

Comment 12 by, Mar 10 2013

Project Member
Labels: -Area-UI -Feature-Fonts Cr-Content-Fonts Cr-UI

Comment 13 by, Apr 6 2013

Project Member
Labels: Cr-Blink

Comment 14 by, Apr 6 2013

Project Member
Labels: -Cr-Content-Fonts Cr-Blink-Fonts

Sign in to add a comment