Chrome/Chromium use "Thin" as default font weight

Well, the package installs a bunch of font weights:

$ dpkg-query -W fonts-noto-cjk
fonts-noto-cjk 1:1.004+repack1-1
$ fc-match -a | grep 'Noto Sans CJK SC'
NotoSansCJK.ttc: "Noto Sans CJK SC" "Regular"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Medium"
NotoSansCJK.ttc: "Noto Sans CJK SC" "DemiLight"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Light"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Thin"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Bold"
NotoSansCJK.ttc: "Noto Sans CJK SC" "Black"

Explicitly setting the font in Chrome/Chromium is discussed as a workaround in the Ask Ubuntu question you asked (<http://askubuntu.com/q/763632>). One question is if the problem lies in Chrome/Chromium, or if it would be possible to fix it in the fontconfig package by further tweaking the font weights handling (see bug #1556457).

I'm not sure that's the case... As I described in the original report, once I uninstalled the package and manually downloaded NotoCJK from Google, the issue is fixed, even though I didn't make any changes in the Chrome font settings (the default font is still "Liberation Sans" now). In my original noto folder, there is only one NotoSansCJK file, but in the downloaded zip file, there are various files e.g. NotoSansCJKsc-Regular.otf, NotoSansCJKsc-Bold.otf etc. Maybe this package just packs all of them into one, but then it's likely a fontconfig issue as of why Chrome decided that "Thin" is the correct one to use.

Could the package just install all weights in separate files just the way they're downloaded at Google website https://www.google.com/get/noto/#sans-hans, instead of putting them into one file? Should that make a difference? This approach seems to solve the issue in Chrome for me.

Status changed to 'Confirmed' because the bug affects multiple users.

I have been having the same issue, except I noticed it for Japanese font rendering (though it also affects Chinese etc).

Chrome selects CJK JP thin for all lang="ja" (when falling back to "sans-serif" at the end of the font stack) regardless of css font-weight specified.

ubuntu Mate 16.04 here. What is worse is that fonts-noto-cjk is a dependency of ubuntu-mate-core and ubuntu-mate-desktop and purging fonts-noto-cjk will also purge ubuntu-mate-core and installing back ubuntu-mate-core will also installing back fonts-noto-cjk.

My current settings in Chrome in this ubuntu Mate 16.04 is, in Customize fonts... -> Advanced Font Settings, set Latin to use "Noto sans" for sans-serif, "Noto serif" for serif, "Noto Mono" for fixed-width, and set Simplified Han to use "Noto Sans CJK SC" for serif and sans-serif, "Noto Sans Mono CJK SC" for fixed-width, and similarly for Traditional Han and Japanese. This works beautifully in pages that explicitly set lang="ja" or lang="zh" or similar in HTML, e.g. Wikipedia. But in pages that not explicitly set lang="??" (for example, https://www.google.com/#q=ceshi), it will render those Simplified Chinese characters using "Noto Sans CJK JP Thin". The expected behaviour is to render them using "Noto Sans CJK SC Regular". Why JP and why Thin? And this actually happens on every pages that does not explicitly set lang="??"(Yes, it will also use "Noto Sans CJK JP THIN" to render a full-of-Japanese page that does not explicitly set lang="ja")

I don't know who causes this bug...But googled for a while and looks like that Chrome ignores system fontconfig, so I guess it may be a bug of font configuration/fallback mechanism inside Chrome...

@Dhoulmagus In your case maybe you can try to replace the font file installed by fonts-noto-cjk directly as a temporary measure. According to http://askubuntu.com/a/762910/391188 and http://takeson.blogspot.com/2016/04/noto-sans-cjk-thin-font-issue.html this method should work, though I haven't tried it myself.

The result of the Taiwan method is to render Traditional Chinese using Noto Sans CJK [JP] Medium, which is apparently still abnormal.
But I don't want Regular Only... so I did not try the first approach either.
And substitute /usr/share/fonts/opentype/noto/NotoSansCJK.ttc with the All-in-one Super OTC pack in https://www.google.com/get/noto/help/cjk/ did not work either...
I'm trying to installing separate font files and see if this works...(God damn the Font Manager in ubuntu repo is also not functional...needs to use the PPA one. We could never stop messing around could we)

After some time of messing around I still think this is a bug of CJK fallback mechanism in Chrome...After all, when the page explicitly sets lang="??", Chrome render the fonts using the corresponding language's Noto Sans CJK ?? correctly and gorgeously(That is, for an entry of Wikipedia, Chrome correctly renders its English version using Noto Sans, Noto Serif, Noto Mono, and correctly renders its Japanese version using Noto Sans CJK JP, and correctly renders its SC version using Noto Sans CJK SC and TC version using Noto Sans CJK TC. And Chrome correctly renders normal texts using Regular fonts and renders bold texts using corresponding Bold fonts. This means that Chrome CAN RECOGNIZE different Noto CJK fonts and their different Weights), but when the page does not explicitly sets lang="??", its fallback mechanism will weirdly choose [Noto Sans CJK JP Thin] first to render CJK fonts, which is the key.

Inspired by what JI Xiang reported above, and as an experiment, I created a version of fonts-noto-cjk, which installs 36 individual font files instead of the NotoSansCJK.ttc bundle, and uploaded it to this PPA:

https://launchpad.net/~gunnarhj/+archive/ubuntu/fonts-noto-cjk

Seems to work, which indicates that there is some incompatibility between Google's NotoSansCJK.ttc bundle and Google's own web browser.

There is a big problem with this solution, though: The .deb file in the PPA is huge, really huge: 372 MiB to be compared with the original .deb file of 71 MiB.

It should be said that neither Google Chrome nor Chromium is included by default in Ubuntu. Considering that, and taken into account that fonts-noto-cjk is included in the ISO files of both Ubuntu and the flavors, it's not likely that adding 300 MiB to work around this issue will be considered a reasonable measure.

So probably we need another solution. But in the meantime the PPA is available for your convenience. :)

Submitted this issue: https://github.com/googlei18n/noto-cjk/issues/65

A discussion with Aron Xu and Sebastien Bacher on IRC resulted in the idea that we create an additional binary package and move some of the font files to that package. So now there are two .deb files in the PPA: fonts-noto-cjk and fonts-noto-cjk-extras.

fonts-noto-cjk installs these font files:

NotoSansCJKjp-Bold.otf
NotoSansCJKjp-Regular.otf
NotoSansCJKkr-Bold.otf
NotoSansCJKkr-Regular.otf
NotoSansCJKsc-Bold.otf
NotoSansCJKsc-Regular.otf
NotoSansCJKtc-Bold.otf
NotoSansCJKtc-Regular.otf

With those files, the size of the .deb file is 85 MiB (the size of the .deb currently in the archive is 71 MiB).

fonts-noto-cjk-extras, which is optional, installs the other 28 font files. fonts-noto-cjk-extras will not be included in the ISO files, but Chinese users will be prompted to install it via Language Support.

I tested to replace the single "super" OTC file with 7 weight specific OTC files, and it seems like this is sufficient to fix "the Thin issue" in Chrome/Chromium. So I have uploaded a simpler proposal to the PPA. This variant increases the archive space utilization only fractionally (73 MiB instead of 71), so no need to break out certain files to a new binary.

Fixed via autosync

I uploaded the xenial backport to the SRU queue now, thanks!

Is this done or not? still not work for me

On 2016-05-07 02:39, Hong Zhu wrote:
> Is this done or not?

In yakkety yes, in xenial (16.04) not yet. Since it's a change of a stable release, there are some procedures in place to prevent a regression. Will probably take a week or two.

Hello JI, or anyone else affected,

Accepted fonts-noto-cjk into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/fonts-noto-cjk/1:1.004+repack2-1~ubuntu1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Installed fonts-noto-cjk 1:1.004+repack2-1~ubuntu1, and confirmed that it fixes the issue using the "Test Case" in the bug description.

After installing fonts-noto-cjk 1:1.004+repack2-1~ubuntu1, Chrome starts to render CJK characters with Noto Sans CJK [JP] Regular in pages that does not define lang="ja"/lang="zh"/lang="zh-TW"/lang="zh-CN"...
i.e. When the page does not specifies lang="??" in HTML, Chrome will choose Noto Sans CJK JP series to render CJK characters as fallback.
This may be ideal for Japanese users, but I personally would like Noto Sans SC as fallback, as a SC user.
For example, in this page: https://www.google.com/?ion=1&espv=2#q=%E9%97%A8 I want "门" in SC instead of JP.
Is there any way the user can manually set the CJK fallback font(in Chrome, or in somewhere else)?
If such setting exists, JP users can set Noto JP as default fallback, TC users can set Noto TC as default fallback, and so can SC, and this issue can then be treated as fixed.

And finally, if this can be done, it can be expected that this time, ALL CJK characters in a page without lang="??" which is a mixture of CJK fonts(http://www.gamer.com.tw for example) will be rendered in Noto Sans CJK SC. This is still not perfect.
The ultimate ideal form is that Chrome will "intelligently" render Japanese(Hiragana, Katakana, and Japanese Kanji) in Noto JP, render Traditional Chinese in Noto TC, and Simplified Chinese in Noto SC, even in non-lang="??"-specified pages. This is one of the perfect forms:
https://en.wikipedia.org/wiki/Help:Multilingual_support_(East_Asian)
Thanks to that each CJK paragraph is explicitly specified with lang="??" in HTML, this is fulfilled. But in normal pages, uh, I guess this is Mission Impossible...

On 2016-05-12 21:03, Dhoulmagus wrote:
> For example, in this page:
> https://www.google.com/?ion=1&espv=2#q=%E9%97%A8 I want "门" in SC
> instead of JP.

Then a stupid question from someone who doesn't understand any CJK characters: How significant is the difference in appearance?

Another question: Does also Firefox fall back to JP when rendering pages which are not language specified?

> Is there any way the user can manually set the CJK fallback font(in
> Chrome, or in somewhere else)?

Yes, there are such ways. Actually, if your session language is
zh_CN.UTF-8, then the fontconfig configuration makes SC the default.

However, if I understand it correctly, Chrome doesn't care about fontconfig. OTOH you can specify the font in Chrome's "Settings" (advanced).

GH, thank you for putting this in.

At standard body text font size, around 14px for websites, thin width is a lot less scan-able. You have to make an effort to read it. The feeling is similar to reading "Courier New" body text. You can read it if you make an effort, and you can get accustomed to it, however, it reduces UX by a lot.

The "门" problem exists without the proposed font package installed.

For the "门" issue Dhoulmagus mentioned, please see:
https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/1468027

Gunnar mentioned that the Noto Sans CJK JP has the first priority in a fc-match listing, and there is no reason to prefer Chinese over Japanese just for the sake of it.
And as Dhoulmagus mentioned above, rendering non-lang-specified CJK content with per glyph "intelligently" is nearly impossible...

This bug was fixed in the package fonts-noto-cjk - 1:1.004+repack2-1~ubuntu1

---------------
fonts-noto-cjk (1:1.004+repack2-1~ubuntu1) xenial; urgency=medium

  * No-change backport to 16.04 as SRU to fix display problems in Chromium.
    (LP: #1575555)

 -- Iain Lane <email address hidden> Thu, 05 May 2016 15:28:24 +0100

The verification of the Stable Release Update for fonts-noto-cjk has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

An instructive post. People to really know who they want to reach and why or else, they’ll have no way to know what they’re trying to achieve. People need to hear this and have it drilled in their brains..
Thanks for sharing this great article.
https://notresponding.net/firefox-fix/