Chrome/Chromium use "Thin" as default font weight

Bug #1575555 reported by JI Xiang on 2016-04-27
This bug affects 6 people
Affects Status Importance Assigned to Milestone
fonts-noto-cjk (Debian)
Fix Released
fonts-noto-cjk (Ubuntu)
Gunnar Hjalmarsson
Gunnar Hjalmarsson

Bug Description


Chromium and Google Chrome use "Thin" as the default Noto Sans CJK font weight, which makes some Chinese and Japanese web pages difficult to read, and thus gives a bad user experience.

The fonts-noto-cjk version in the PPA

installs 7 weight specific font files instead of a single "super" file. This works around the Chromium/Chrome issue.

Note: It has been fixed in yakkety via autosync, so "backporting" yakkety (as an SRU) instead of uploading from the PPA is an option.

[Test Case]

To reproduce the bug:

* Install Chromium or Google Chrome.
* Go to <> and notice the very thin characters.
* Install fonts-noto-cjk from the PPA and notice the difference.

[Regression Potential]

This is about another font packaging form, without any change in glyph coverage, so the the regression risk should be low.

[Original description]

The package seems to only "thin" variant of the font, which makes it very unreadable in applications such as Chrome (when it has to fall back on Chinese fonts on a mostly-English page). I had to remove the package and then manually download the font from Google website and install it to make the regular weight available

Release: 16.04 LTS
Package Version: 1.004+repack1-1
Expected: All weights of the noto cjk font to be installed
Happened: Only the "thin" weight of the font seems to be installed

Gunnar Hjalmarsson (gunnarhj) wrote :

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 (<>). 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).

summary: - The package seems to only install "thin" weight of the font
+ Chrome/Chromium use "Thin" as default font weight
JI Xiang (szjx) wrote :

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.

JI Xiang (szjx) wrote :

Could the package just install all weights in separate files just the way they're downloaded at Google website, instead of putting them into one file? Should that make a difference? This approach seems to solve the issue in Chrome for me.

Launchpad Janitor (janitor) wrote :

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

Changed in fonts-noto-cjk (Ubuntu):
status: New → Confirmed
Duncan (duncan-bay) wrote :

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.

Dhoulmagus (jiongrious) wrote :

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

JI Xiang (szjx) wrote :

@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 and this method should work, though I haven't tried it myself.

Dhoulmagus (jiongrious) wrote :

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 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)

Dhoulmagus (jiongrious) wrote :

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.

Gunnar Hjalmarsson (gunnarhj) wrote :

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:

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. :)

Gunnar Hjalmarsson (gunnarhj) wrote :

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:


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.

Changed in fonts-noto-cjk (Ubuntu):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Medium
status: Confirmed → In Progress
Changed in fonts-noto-cjk (Ubuntu Xenial):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Medium
status: New → In Progress
Changed in language-selector (Ubuntu):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Medium
status: New → Triaged
Changed in language-selector (Ubuntu Xenial):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
importance: Undecided → Medium
status: New → Triaged
description: updated
description: updated
Gunnar Hjalmarsson (gunnarhj) wrote :

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.

description: updated
no longer affects: language-selector (Ubuntu Xenial)
no longer affects: language-selector (Ubuntu)
Changed in fonts-noto-cjk (Debian):
status: Unknown → New
description: updated
Changed in fonts-noto-cjk (Debian):
status: New → Fix Released
Gunnar Hjalmarsson (gunnarhj) wrote :

Fixed via autosync

Changed in fonts-noto-cjk (Ubuntu):
status: In Progress → Fix Released
description: updated
Iain Lane (laney) wrote :

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

Hong Zhu (hankzhu) wrote :

Is this done or not? still not work for me

Gunnar Hjalmarsson (gunnarhj) wrote :

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 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See 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 . Thank you in advance!

Changed in fonts-noto-cjk (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed
Gunnar Hjalmarsson (gunnarhj) wrote :

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.

tags: added: verification-done
removed: verification-needed
Dhoulmagus (jiongrious) wrote :

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: 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( 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:
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...

Gunnar Hjalmarsson (gunnarhj) wrote :

On 2016-05-12 21:03, Dhoulmagus wrote:
> For example, in this page:
> 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).

voidvector (voidvector) wrote :

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.

tomoe_musashi (musashi) wrote :

For the "门" issue Dhoulmagus mentioned, please see:

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...

Launchpad Janitor (janitor) wrote :

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

Changed in fonts-noto-cjk (Ubuntu Xenial):
status: Fix Committed → Fix Released

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.

Firefox Fix (firefoxfix) wrote :

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.