blocks 2677 (and others)

Bugs blocked by/related to this issue are :

issue 2938, issue 1328, issue 1646
issue 1810, issue 2377

Also see issue 3058

issue 2685 depends on this. 

Issue 7160 has been merged into this issue.

Webkit bugs related to this are 

http://bugs.webkit.org/show_bug.cgi?id=10874
http://bugs.webkit.org/show_bug.cgi?id=20797

Moving from milestone 2 to milestone 2.1.

This doesn't seem like a BrowserUI bug to me...

Punting to 4.0. I took a first step in webkit patch, but it's gonna take a while to get 
it accepted. I'll take a different approach to get it accepted faster. Anyway, it's not 
gonna make it 3.0. 

Issue 2510 has been merged into this issue.

Issue 1646 has been merged into this issue.

Issue 2677 has been merged into this issue.

Issue 15804 has been merged into this issue.

Any progress on this?

I dont think so..

This is the second thing preventing me from using Chrome full time.  :(  I want all
my Japanese and Korean sites to use better fonts.

An additional detail is the rendering differences between the following: zh, zh-Hans, 
zh-CN, zh-SG, zh-Hans-CN, zh-Hans-SG, zh-Hant, zh-TW, zh-HK, zh-Hant-TW, zh-Hant-HK.

From what I have gathered... there are really two flavors of these characters for 
Chinese... traditional (zh-Hant) and simplified (zh-Hans). With the attached test 
page... they all look the same in Chrome at the moment. However... if you run it in 
Firefox... zh-Hant, zh-TW and zh-HK show up as I would expect. zh-Hant-TW and zh-
Hant-HK however seem to go back to simplified... which at least to my zero chinese 
knowing self... seems incorrect. 

cjk.html 16.8 KB View Download

Yeah, CJK glyph preference difference is one of motivations for this bug. My webkit 
patch for this bug took another twist. So, I'm punting it for now, but I'm hoping to 
get it done for real before long. 

So, if I understand correctly, this is waiting on the Webkit changes?

I may or may not be able to get to this in M6 frame. 

Japanese is still showing up as Chinese characters - seems to me like a major limitation of an otherwise excellent web browser given that Japan one of the best connected (speaking of internet access) countries in the world.

Basically what's missing is the ability to tell webkit how to disambiguate the inherently script-agnostic unicode encoding. When the encoding is Unicode, that's not enough to determine what the text should look like, it only specifies which codepoint a letter references. In addition to this, the render engine needs to be able to determine which script is being used, so that the selection of which character X that maps to codepoint Y should be used. 

A possible option is to add an expanded selector to the Unicode encoding option:

Encoding [>]
  Unicode (UTF-8) [>] 
    --- Arabian ----
    [x] default
    [ ] Traditional
    [ ] Nasta'liq
    [ ] Shahmukhi
    [ ] Ajami
    [ ] ...
    --- CJK ---
    [x] default
    [ ] Chinese (traditional)
    [ ] Chinese (simplified)
    [ ] Japanese
    [ ] Korean
    [ ] Vietnamese (Chữ Nôm)
    [ ] Vietnamese (Hán tự)
    [ ] ...
    --- Etcetera ---
    [x] default
    [ ] ...

At least in this way a user would be able to make the engine render text correctly. Of course finding the right font for each script will be a problem, and would likely require a dedicated preferences tab so that users can set the font for each script themselves, instead of blindly trusting the render engine (which will be guaranteed to get it wrong). Perhaps even a greyed out option in the script selector, only allowing 'default' handling until the user has set a specific font for a specific script.

Issue 55919 has been merged into this issue.

nice to see this two-year-old is still updating, hope its not only the milestone label

Since we are passed the branch, moving all mstone-8 issues to mstone-9 for triage/punting

What is the purpose of a milestone label that keeps getting bumped into the future time and time again?

Might as well mark the issue WONTFIX BYDESIGN or whatever. At least that'd be more honest.

>dngnta

That's what I really want to say in comment 37..
but I still wish this basic function be included in Chrome..

Just want to ask if there is still anyone following it

at least post some progress perhaps? 
it looks like nothing has been done for this

This is just the biggest fail on any big software I've ever seen. How can you display chinese, japanese or korean character with the same font ? That's just insane, and the worst is that this issue has been discovered 4 years ago. What are you doing ? I'm learning japanese and because of chrome/webkit, I'm getting used to the wrong characters. You suck, I'm gonna get back to firefox as soon as the 4th version's here.

Move to M11 from M10, as we've now branched.  If you believe this bug was moved in error, please come talk to me.

Issue 73016 has been merged into this issue.

rolling non releaseblocker mstone 11 bugs to mstone 12. 

Moving out of M12.

Moving out of M12.

> 2.5 years since bug first reported... Could someone please address this? This is a major pain.

Moving !type=meta|regression and !releaseblocker to next mstone

This bug was just raised again today on our Japanese language learning forum when a user was confused by getting the wrong kanji displayed rather than the one they expected, because Chrome was showing them the Chinese hanzi rather than the Japanese kanji. I opened Chrome 12.x and saw that sure enough, this bug was STILL present.

I should also mention that not only is it wrong, but it also looks ugly to use serifed hanzi fonts mixed in with sans-serif Japanese kana etc.

I personally went back to using Firefox after seeing this bug continually shuffled along with no resolution for so long (since I work with Japanese language learning websites, this bug is really a show stopper for me).

Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.

It is not a non-critical bug. Please fix it.

This is critical for some users and we are working on it, but we cannot make it
for M14.

This is a non-ciritical bug in the sense that this needs urgent fix such as
crash or security vulnerability.

Thanks for your patience.

Issue 59541 has been merged into this issue.

moving non-essential bugs to m16. please move back if you think this is an error.

Issue 29391 has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=109407

------------------------------------------------------------------------
r109407 | falken@chromium.org | Thu Nov 10 02:14:41 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/tab_contents/tab_contents_wrapper.cc?r1=109407&r2=109406&pathrev=109407

Observe per-script font preferences so WebKit settings are updated when they change.

Also, observe cursive/fantasy font prefs.

This will help allow for more advanced font settings UI than are currently available, such as for per-script fonts.

BUG= 2685 
TEST=manually, changed a per-script pref and saw it take effect


Review URL: http://codereview.chromium.org/8508002
------------------------------------------------------------------------

This needs to be fixed.  Khmer looks horrible in Chrome because Microsoft supplied terrible fonts for Khmer.  We should be able to specify fonts like we can in Firefox.

This is a big, major bug for anybody surfing the Japanese web and it has been known since 2008. When do you intend to fix it!? It's the only thing that stops me from using Chrome exclusively over Firefox.

Thank you for your patience and I agree that this is a very important missing feature. 

We've worked on this recently. Some Chrome-side (preferences, etc) have already been added. We're trying to persuade Chrome UI to add a UI for this feature while we're blocked by a webkit review process to finish this up on Webkit's end. 

jshin, thank you for your candidness and patience with us users. I know I'm preaching to the choir here, but for many people this is the last niggling issue with Chrome. What a wonderful new world we will be living in once this is fixed ;-)

Moving bugs marked as Started but not blockers from M17 to M18.  Please move back if you think this is a blocker, and add the ReleaseBlock-Stable label.  If you're able.

With dev-channel 18.0.1003.1 Japanese characters now seem correct in both Japanese wikipedia and the Han unification page on the English wikipedia, even when the UI language is set to English. Am I imagining things or did this bug finally get fixed? If so, thank you so very much!

Additional works to do:

1. Enhane UI for font settings dialog to let users configure per-script / per-lang font
2. Webkit bug https://bugs.webkit.org/show_bug.cgi?id=76673 to use per-script font preference in the final (last resort) font selection when 'lang' is not specified or when fonts specified in CSS and fonts for 'lang' do not cover a character in question.  This bug is for Windows Chromium only, but we have to do the same for Linux/CrOS and Mac OS. 

The font settings UI is going to be offered as an extension. The extension API for that is being worked on in bug 114148. 

bug 114805 is about an extension that uses the API proposed in bug 114148. 

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=127436

------------------------------------------------------------------------
r127436 | falken@google.com | Mon Mar 19 00:32:16 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/api/fontSettings.zip?r1=127436&r2=127435&pathrev=127436
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/experimental.downloads.html?r1=127436&r2=127435&pathrev=127436
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/api/experimental.fontSettings.json?r1=127436&r2=127435&pathrev=127436
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/samples.json?r1=127436&r2=127435&pathrev=127436
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/api/fontSettings/popup.html?r1=127436&r2=127435&pathrev=127436
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/samples.html?r1=127436&r2=127435&pathrev=127436
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/api/storage/stylizr.zip?r1=127436&r2=127435&pathrev=127436
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/pref_names.cc?r1=127436&r2=127435&pathrev=127436
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/experimental.fontSettings.html?r1=127436&r2=127435&pathrev=127436

Add more scripts for per-script font preferences.

BUG= 2685 
TEST=manually

Review URL: https://chromiumcodereview.appspot.com/9699110
------------------------------------------------------------------------

There is an experimental font settings extension API available on the beta and dev channel: http://code.google.com/chrome/extensions/trunk/experimental.fontSettings.html

As mentioned on that page, there is also a sample extension but it interfaces with the latest version of the API, which may be different than the beta/dev channel versions.

These bugs have hit their move limit.  Please re-target as appropriate.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=142104

------------------------------------------------------------------------
r142104 | falken@google.com | Wed Jun 13 22:51:50 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/api/fontSettings.zip?r1=142104&r2=142103&pathrev=142104
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/api/fontSettings/popup.js?r1=142104&r2=142103&pathrev=142104
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/samples.json?r1=142104&r2=142103&pathrev=142104
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/api/experimental_font_settings.json?r1=142104&r2=142103&pathrev=142104
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/pref_names.cc?r1=142104&r2=142103&pathrev=142104
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/experimental.fontSettings.html?r1=142104&r2=142103&pathrev=142104

Add per-script font support for all ISO 15924 scripts.

Special script codes Zinh, Zxxx, Zzzz, Qaaa-Qabx are excluded.  Also, the
various Japanese script codes Hira, Kana, and Jpan are excluded in favor of the
single code Hrkt; likewise, for Korean, Kore is excluded in favor of Hang.
Hrkt and Hang are used just because they currently are already included; this
is planned to change in a separate patch
<https://chromiumcodereview.appspot.com/10532105>

BUG= 2685 
TEST=

Review URL: https://chromiumcodereview.appspot.com/10548021
------------------------------------------------------------------------

Issue 133706 has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=144418

------------------------------------------------------------------------
r144418 | falken@chromium.org | Wed Jun 27 01:25:19 PDT 2012

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/prefs/prefs_tab_helper.cc?r1=144418&r2=144417&pathrev=144418
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/static/experimental.fontSettings.html?r1=144418&r2=144417&pathrev=144418
 M http://src.chromium.org/viewvc/chrome/trunk/src/webkit/glue/webpreferences.cc?r1=144418&r2=144417&pathrev=144418
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/api/fontSettings/popup.js?r1=144418&r2=144417&pathrev=144418
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/samples.json?r1=144418&r2=144417&pathrev=144418
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/examples/api/fontSettings/popup.html?r1=144418&r2=144417&pathrev=144418
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/api/experimental_font_settings.json?r1=144418&r2=144417&pathrev=144418
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/pref_names.cc?r1=144418&r2=144417&pathrev=144418

Use ICU script code "Jpan" instead of "Hrkt" in Japanese pref names.

The script code "Jpan" ("Japanese") is more suitable for naming font prefs for rendering Japanese than "Hrkt" ("Hiragana or Katakana").

With this change, the script code used in Chrome pref names for Japanese will become different than the one used in WebKit settings. We would have used "Jpan" in both Chrome and WebKit to begin with, but it is a newer script code that the version of ICU included in WebKit for MacOS doesn't have. But since Chrome now exposes script codes in the Font Settings Extension API, it's better to use the more appropriate, modern one. This patch just changes the script used internally by Chrome and translates it to the one used by WebKit when talking to WebCore.

BUG= 2685 
TEST=browser_tests --gtest_filter=ExtensionApiTest.FontSetting*
TBR=pkasting,mpcomplete

Review URL: https://chromiumcodereview.appspot.com/10532105
------------------------------------------------------------------------

Issue 62471 has been merged into this issue.

It seems that this is already fixed on Windows, but not on Linux - can anybody confirm that?

When I view the English Wikipedia page on "Han unification" on Windows, the Japanese versions of the characters are correctly displayed; on Linux, however, the Chinese variant is shown for all of them.

It works on Firefox and Linux, so my font configuration should be fine. Also, it works when manually forcing a Japanese font for Japanese text in the experimental extension.

Could it be that while Chromium does honor the HTML lang tag, it isn't able to find a matching font on Linux by default? On my system, that seems to be directed by a configuration file in /etc/fonts. There are some mappings for various languages and appropriate fonts for them, which seems to be exactly the information Chrome would need.

Not exactly working in Windows, either.  I'm on Win 7 and latest version of Chrome and had to change all the default fonts in the advanced preferences to things like MS Mincho, etc. to get Japanese characters to show up rather than simplified Chinese.

Out of box, Chrome will not have the UI for setting font preferences per script. However, there's an extension to allow this configuration by users. 

See https://chrome.google.com/webstore/detail/advanced-font-settings/caclkomlalccbpcdllchkeecicepbmbm?hl=en

The reason the behavior seems to be different on Linux vs Windows is that more scripts have the default fonts set for Windows than on Linux. If you install the extension, you can set fonts per script to meet your needs on Linux. 

I've checked out the extension, and manually setting the correct font for various languages works indeed.

That's not very convenient for new users, however, and there has to be a way to do it right - after all, both Firefox and Opera get it right out of the box.

It seems to me that unlike most other Linux applications, Chrome doesn't respect the configuration files in /etc/fonts/conf.d/, which seems to contain the preferred fonts per language in several XML files on my system (I've attached the one for Japanese as an example).

There is obviously enough metadata to make a better decision for the right font for a given language than just the Unicode code points, which Chrome seems to do.

69-language-selector-ja-jp.conf 9.6 KB Download

Issue 234500 has been merged into this issue.

I installed the above extension, 
and set Chinese to Microsoft jhenghei, 
and leave the English as default.

However, Chrome use "Microsoft jhenghei" for all words in Chinese encoded website including the English word, which make them so weird.

Why couldn't Chrome use the same method as Firefox to change font?
This is 2008 issue and 2014 is coming soon, and still not fixed yet?

我觉得chromium浏览中文网页跟Firefox比起来弱爆了.
When rending Chinese fonts, Chromium is holly shit!

You can use this chrome extension for now to configure per-locale default font family mapping:

https://chrome.google.com/webstore/detail/advanced-font-settings/caclkomlalccbpcdllchkeecicepbmbm

re comment 86: see bug 424870 (BTW, I don't think tweaking fontconfig is a user-friendly way to configure fonts. That's why @falken made an extension mentioned in comment 92). See also bug 403915 (Chrome now respects fontconfig font settings).