Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Issue 368442 Noto Sans CJK and Roboto : Only two weights are accessible with font-weight out of 6 or 7 weights.
Starred by 25 users Project Member Reported by js...@chromium.org, Apr 29 2014 Back to list
Status: Fixed
Owner:
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Chrome
Pri: 2
Type: Bug

Blocked on:
issue 333354

Blocking:
issue 617281



Sign in to add a comment
Version: 36.x
OS: Linux, Chrome OS

What steps will reproduce the problem?
1. Install a font whose name id 1 (font family name) is different from name id 16 (preferred font family name) [1] 
2. Use id 16 in the CSS (font-family) and make a page with such a css
3. Load a page 

What is the expected output? What do you see instead?

Expected: 
The font specified in CSS is used. 

Actual: 
A fallback font is used. 

This bug is yet speculative. I'll get back with more details and debugging. 

My current suspicion is that we're rejecting such a font because of an incorrect family name match checking we apply. 

Refrences: 
1.  https://www.microsoft.com/typography/otspec/name.htm (Name IDs table)
2.  https://bugzilla.mozilla.org/show_bug.cgi?id=586037#c11 : fontconfig change made by kpackard. The fc-bug that triggered that change is 
https://bugs.freedesktop.org/show_bug.cgi?id=7673

[1] It's common to have name id 1 different from name id 16 if a font family has more than 4 combinations of styles (weight, width and italic vs  upright) because name ids 1 + 2 can only support 4 combinations while name ids 16+17 can support a lot more combinations. 

 
Comment 1 by js...@chromium.org, Aug 8 2014
Cc: derat@chromium.org
Summary: Only 2 weights out of 7 in Noto Sans CJK / Korean/Japanese/Hans/Hant are accessible (was: Font with name id 1 != name id 16 is not accepted)
This bug was filed before Noto Sans CJK was released/announced [0]. As far as 'regular' and 'bold' are concerned, it's fine. However, when we want to use other weights [1], they're not accessible by specifying 'font-weight: [100|300|500|700|900]'

* How to reproduce? 

1. Go to www.google.com/get/noto and select all languages or Korean/Japanese/Simp Chinese/Trad Chinese
2. Install fonts by copying them to ~/.fonts (or a system font directory if you wish to)
3. Remove 'NotoSans*DemiLight*' to separate this bug from a fontconfig issue with DemiLight [1]

4. Run 'fc-list "Noto Sans Korean" family weight style and confirm that there are 6 fonts listed

Noto Sans Korean,Noto Sans Korean Thin:style=Thin,Regular:weight=50
Noto Sans Korean,Noto Sans Korean Thin:style=Thin,Regular:weight=0
Noto Sans Korean,Noto Sans Korean Bold:style=Bold:weight=200
Noto Sans Korean,Noto Sans Korean Regular:style=Regular:weight=80
Noto Sans Korean,Noto Sans Korean Medium:style=Medium,Regular:weight=100
Noto Sans Korean,Noto Sans Korean Black:style=Black,Bold:weight=210
Noto Sans Korean,Noto Sans Korean Light:style=Light,Regular:weight=50

5. Restart Chrome

6. Go to https://deb53d85a427140a6e10ee61e1ceb3408c8407f2.googledrive.com/host/0B153_ao11p4QR2s3RWRXMUhJa1U/notosanscjk_weights.html

Expected:

2nd column (local font) is the same as 3rd column (web font). 

Actual: column 3 has 6 weights while column 2 has only 2 weights. 



[0] http://googledevelopers.blogspot.com/2014/07/noto-cjk-font-that-is-complete.html
 
[1] DemiLight is a known issue that was fixed recently in fontconfig. 
See https://code.google.com/p/noto/issues/detail?id=43

Cc: bashi@chromium.org dominik....@intel.com
Comment 3 by derat@chromium.org, Aug 8 2014
Cc: asvitk...@chromium.org bunge...@chromium.org reed@chromium.org
What happens on 38? Pretty much all font-related code has changed greatly since 36.

FontRenderParams only supports passing FC_WEIGHT_BOLD and FC_WEIGHT_NORMAL to Fontconfig (since it uses gfx::Font::FontStyle), but that's only used to determine the font rendering settings (not the family) for web content.

I'm guessing that this falls somewhere between Blink and Skia, but I'm not sure where. The initial comment on issue 395313 has some pointers to code that may be relevant.
At the moment, I'm currently trying to fix this for Android in M38. However, there is also https://codereview.chromium.org/396143004/ which is the start of fixing this for Linux.
Comment 5 by js...@chromium.org, Aug 9 2014
@derat, thank you for the reply and a pointer to bug 395313

M38 (Version 38.0.2114.2 unknown (64-bit)) has the same problem, but perhaps it's a bit old build in light of your recent changes. Let me try a ToT build. 


> that's only used to determine the font rendering settings (not the family) for 
> web content

I'm not sure I understand the above comment as to why passing one of only two FC_WEIGHT_{BOLD,NORMAL}  does not affect this issue. 

As shown in comment 1 [1] , all 7 weights of 'Noto Sans Korean' has the same family name (name table id=16) although for 'old' programs that do not honor name id=16, they also have name id=2 with 'weight' attached to the family name. Fontconfig returns both names (e.g. Noto Sans Korean and Noto Sans Korean Thin for Noto Sans Korean wi


[1] The output of 'fc-list' in comment #1 is confusing because it has two entries for 'Thin'. There are two 'Thin' entries in comment #1 because I installed two instances of Thin (one for Linux/Mac and the other for Windows. The latter has OS2.fsWeight set to 250 to work around a Windows behavior of fake-bolding any font with OS2.fsWeight < 250).  What's below is what you'd expect with all 7 weights installed on Linux without the Thin for Windows. If you remove DemiLight, you'll have 6 lines of output from 'fc-list "Noto Sans Korean" family style weight'. 

Noto Sans Korean,Noto Sans Korean Thin:style=Thin,Regular:weight=0
Noto Sans Korean,Noto Sans Korean Bold:style=Bold:weight=200
Noto Sans Korean,Noto Sans Korean Regular:style=Regular:weight=80
Noto Sans Korean,Noto Sans Korean Medium:style=Medium,Regular:weight=100
Noto Sans Korean,Noto Sans Korean Black:style=Black,Bold:weight=210
Noto Sans Korean,Noto Sans Korean DemiLight:style=DemiLight,Regular:weight=80
Noto Sans Korean,Noto Sans Korean Light:style=Light,Regular:weight=50
Comment 6 by js...@chromium.org, Aug 9 2014
@bungeman, glad to know that you're working on it. 

Attached is the screenshot comparing Firefox (left) and Chrome 38 (right). Aside from the rendering difference [1], the left (firefox) has all 6 weights (I dropped DemiLight for this screenshot due to a fontconfig issue) when these fonts come locally or via web font. The column 2 of the right (Chrome 38) has only two weights (100, 300, 400, 500 all use Noto Sans Korean with weight=400 and 700 and 900 use Noto Sans Korean Bold). The column 3 in Chrome has 6 different weights. 




notoweighs_fx_vs_cr.png
66.8 KB View Download
Comment 7 by derat@chromium.org, Aug 9 2014
#5:

> > that's only used to determine the font rendering settings (not the family) for 
> > web content
> 
> I'm not sure I understand the above comment as to why passing one of only two
> FC_WEIGHT_{BOLD,NORMAL}  does not affect this issue.

I meant that gfx::FontRenderParams is only used to determine antialiasing, hinting, and subpixel rendering settings for Blink, so it doesn't seem like it's relevant here.
Looking at the developer tool's computed style on Chrome(38.0.2125.101 r290379, Blink 537.36 @183011), only one weight of the font is used. And not just CJK text, all bold text is just regular font emboldened.
Also it always picks the regular font with fontconfig's normal font weight(100?). As a result, Noto Sans CJK Medium is picked. Therefore on pages with both CJK and Latin text, normal text would be shown with mixed font weights: Noto Sans Regular and Noto Sans CJK Medium.
Comment 9 by e...@chromium.org, Oct 10 2014
Blockedon: chromium:333354
We have support for numeric font weights and font-stretch on windows, support on other platforms is blocked on skia implementing matchFamilyStyle on linux, android and mac.

Comment 10 by js...@chromium.org, Oct 11 2014
> all bold text is just regular font emboldened.

Hmm... It cannot be true.  

 A long time ago (even before Blink was born), I suspected that that's what's done by a CL to Webkit, but no reviewer agreed with me and I thought I had misread the CL. 

re: comment 9 : thanks for the pointer. The other day, I was looking at the SkTypeFace and was surprised that it has only isBold and isItalic (instead of weight, stretch and slant).

BTW, SkFontStyle does not have CSS generic family (serif, sans-serif, etc). Is it because it's supposed to be dealt with elsewhere? 

Comment 11 by js...@chromium.org, Oct 11 2014
> I thought I had misread the CL.
I meant to verify that, but haven't managed to (moreover, it's highly unlikely that we  have lived with synthetic bolding even when a native bold is available for > 20 releases). 
After some tests, I think my description in #8 is a font fallback issue. If I set the default sans-serif font to "Noto Sans CJK TC" instead of "Sans", then its regular weight and bold weight would be used. The downside is that Latins and numbers would be rendered with the CJK font.

chrome_sans-serif_is_Sans.png:
  sans-serif (Sans):
    weight 100-500: Noto Sans CJK TC Medium
    weight 700-900: Noto Sans CJK TC Medium (emboldened)
  Noto Sans CJK TC:
    weight 100-500: Noto Sans CJK TC Regular
    weight 700-900: Noto Sans CJK TC Bold

chrome_sans-serif_is_Noto_Sans_CJK_TC.png:
  sans-serif (Noto Sans CJK TC):
    weight 100-500: Noto Sans CJK TC Regular
    weight 700-900: Noto Sans CJK TC Bold
  Noto Sans CJK TC:
    weight 100-500: Noto Sans CJK TC Regular
    weight 700-900: Noto Sans CJK TC Bold

firefox.png:
  sans-serif (per fontconfig?):
    weight 100: Noto Sans CJK TC Thin
    weight 300: Noto Sans CJK TC Light
    weight 400: Noto Sans CJK TC Regular
    weight 500: Noto Sans CJK TC Medium
    weight 700: Noto Sans CJK TC Bold
    weight 900: Noto Sans CJK TC Black
  Noto Sans CJK TC:
    weight 100: Noto Sans CJK TC Thin
    weight 300: Noto Sans CJK TC Light
    weight 400: Noto Sans CJK TC Regular
    weight 500: Noto Sans CJK TC Medium
    weight 700: Noto Sans CJK TC Bold
    weight 900: Noto Sans CJK TC Black

font_weights.html
1.0 KB View Download
chrome_sans-serif_is_Noto_Sans_CJK_TC.png
58.8 KB View Download
firefox.png
63.6 KB View Download
chrome_sans-serif_is_Sans.png
75.1 KB View Download
Well, even after I've set the default sans-serif font to the CJK font, if a web page didn't specify sans-serif in the font-family list, I'd still get CJK Medium as regular and emboldened CJK Medium as bold. I think that means when Chrome asks fontconfig for font candidates, it fails to mention the font style.
firefox_implicit_fallback.png
71.0 KB View Download
chrome_implicit_fallback.png
80.0 KB View Download
font_weights.html
1.1 KB View Download
Some additional info: Only in chrome 38+, it select "Noto Sans CJK SC Medium" when Noto font is not specified. It select "Regular" correctly in 37.
And some other screenshot in https://code.google.com/p/chromium/issues/detail?id=418937
And it also happens in other case which used font fallback, such as "Droid Sans" => "Droid Sans Fallback".
Comment 16 by behdad@google.com, Oct 14 2014
Ack.  Our font fallback codepath (at least on some platforms) ignores weight and slant.
Re: #16
I think font fallback ignores family too. See screenshots in https://code.google.com/p/chromium/issues/detail?id=403915#c37
All fonts are serif in font-family, but Chrome selects a sans-serif cjk font as fallback when none of those have cjk glyph. I am sure when I run "fc-match -s" with any of those serif fonts, I will get a serif cjk font listed right after the serif font being matched.
Comment 18 by js...@chromium.org, Oct 18 2014
re comment 17: you're right that 'cssGeneric' (sans-serif, serif, monospace) is not passed to fontconfig when looking for fallback font. 

When lang is specified in web pages and you have per-lang font configured with 'Advanced font settings' extension, that final fallback path won't be hit. 
( go to Settings - Advanced - Fonts where you can install the extension) 

Another BTW: I recommend installing only two weights ('NotoSansCJK-{Regular,Bold}.ttc') until this issue is resolved because Medium is picked in place of Regular as mentioned in comments here. 

Comment 19 by js...@chromium.org, Oct 18 2014
re comment 10: As far as Noto Sans CJK is concerned, synthetic bold is indeed used. This makes 'bold' on Chrome OS look bad on low-res devices (see bug 409079). 

1) data:text/html;charset=utf-8, <span style="font-family: Noto Sans CJK KR; font-weight: bold;">불평등</span>

2) data:text/html;charset=utf-8, <span style="font-family: Noto Sans CJK KR Bold;"> 불평등</span>

#1 is using synthetic-bold while #2 uses the native bold. 

Re #19:

See the pictures in this issue: https://code.google.com/p/chromium/issues/detail?id=418937
I'm sure chrome uses the native bold font when "font-family" is set to "Noto Sans CJK SC", NOT only is set to "Noto Sans CJK SC Bold"!

PS.
I test it again in chrome v38, and get the same result. Here is the screenshot.
bold-v38.png
16.0 KB View Download
Re #19:

I have tested your code, but it also works fine in my computer.
My OS is linux, debian jessie. So is the bug your described only happens in Chrome OS, not all linux distribution?
Comment 22 by js...@chromium.org, Nov 11 2014
Blocking: chromium:409047
Comment 23 by js...@chromium.org, Nov 11 2014
Summary: Noto Sans CJK and Roboto : Not all the weights are accessible with font-weight (was: Only 2 weights out of 7 in Noto Sans CJK / Korean/Japanese/Hans/Hant are accessible )
Roboto (has 6 weights) has the same problem as expected:

http://goo.gl/EGsg0s : a test page. 
The 2nd column uses 'font-family: Roboto; font-weight: (100|300|400|500|700|900)'. The 3rd column uses Web fonts with the corresponding weights. The 4th column is an attempt to work around this bug by specifying 'font-family: Roboto-{Thin,Light,Regular,Medium,Bold, Black}' 
Comment 24 by js...@chromium.org, Nov 13 2014
Summary: Noto Sans CJK and Roboto : Only two weights are accessible with font-weight out of 6 or 7 weights. (was: Noto Sans CJK and Roboto : Not all the weights are accessible with font-weight)
At http://goo.gl/EGsg0s, the 4th column (a work-around attempt by using 'font-family: Roboto-{Thin, Light, Regular, Medium, Bold, Black}' didn't work and the result is exactly the same as the 2nd column (only two weights are used). 

See the screenshot. 


Screenshot from 2014-11-12 16:36:24.png
70.2 KB View Download
Comment 25 by js...@chromium.org, Nov 13 2014
Roboto can be obtained at http://www.google.com/design/spec/style/typography.html 

Attached is a screenshot of Firefox rendering http://goo.gl/EGsg0s. Note that in column 2 and column 4, Thin and Light are identical. That's because Roboto-Thin has fsWeight=250 instead of fsWeight=100 in OS/2 table and fontconfig (up to 2.11.1) maps both fsWeight=250 and fsWeight=300 (Roboto-Light) to the same fontconfigWeight (50). Fontconfig (in the trunk) distinguishes them from each other. (see also http://code.google.com/p/noto/issues/detail?id=200 for Noto Sans CJK whose 1.001 or later version has the same fsWeight=250 for Thin).  


Screenshot from 2014-11-12 16:51:50.png
63.3 KB View Download
Comment 26 by js...@chromium.org, Nov 24 2014
Blocking: chromium:434400
Comment 27 by js...@chromium.org, Nov 25 2014
Blocking: -chromium:434400
Comment 28 by js...@chromium.org, Dec 10 2014
bug 409047 (triaged for M41) is blocked by this bug. If we can fix bug 333354 (blocking this bug), I expect this to be resolved, too. 
Cc: sgabr...@chromium.org abodenha@chromium.org
Now that we're using Roboto for Material Design in Files.app and other places in Chrome OS, we need the ability to render other weights of Roboto. Who would be a good person to work on this?
Comment 30 by e...@chromium.org, Feb 3 2015
Blocked on issue 333354 as that API isn't available on all platforms yet.
Comment 31 by codefu@google.com, Feb 3 2015
What about actually fixing the roboto files? The meta data was *wrong* the last time I looked at them.
codefu@ can you file a bug on what looks wrong in those files and we can try to track down someone to fix them?
Owner: js...@chromium.org
Status: Assigned
jshin@ can you add the additional weights once the blockers are cleared?
Comment 34 by js...@chromium.org, May 22 2015
Cc: js...@chromium.org
Status: Available
abodenha@ : this bug is not about adding more wegiths of Roboto, but is about fixing Blink to support more than 2 weights. 
I'd love to fix Blink to support more than 2 weights, but I can't at the moment. Make it available for now. 


Comment 35 by laforge@google.com, Jun 13 2015
Cc: drott@chromium.org
Comment 36 by laforge@google.com, Jun 13 2015
Attempting to remove dominik.rottsches@intel.com from cc.
Cc: -dominik....@intel.com
Comment 38 by kgr@chromium.org, Oct 1 2015
Cc: kgr@chromium.org
Owner: ----
Comment 40 by e...@chromium.org, Nov 16 2015
Cc: a...@chromium.org tha...@chromium.org eseidel@chromium.org
Issue 449256 has been merged into this issue.
Comment 41 by e...@chromium.org, Nov 16 2015
Cc: dbeam@chromium.org n...@chromium.org
Issue 450326 has been merged into this issue.
Comment 42 by e...@chromium.org, Nov 16 2015
Issue 444609 has been merged into this issue.
Comment 43 by dbeam@chromium.org, Nov 17 2015
Cc: arthurhsu@chromium.org
Owner: thomasanderson@chromium.org
Status: Started
bungeman@: Can you confirm if this is fixed with https://codereview.chromium.org/1873923002/ and https://codereview.chromium.org/1877673002
Comment 47 Deleted
I believe that PlatformFallbackFont is the current bottleneck. It is likely that all of the code changed in https://codereview.chromium.org/1877673002 is effectively dead code. It's hard to tell for sure. The code currently being used appears to be the path that goes through WebSandboxSupport::getFallbackFontForCharacter. I find many of the assumptions made along this path very strange.
Project Member Comment 49 by bugdroid1@chromium.org, Apr 28 2016
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f24ce736e38fa9b159d59dab44b7cc2c69a67849

commit f24ce736e38fa9b159d59dab44b7cc2c69a67849
Author: thomasanderson <thomasanderson@google.com>
Date: Thu Apr 28 18:25:04 2016

Use the new legacyCreateTypeface that has an SkFontStyle parameter

Depends on Skia CL https://codereview.chromium.org/1905253002/
BUG= 368442 

Review-Url: https://codereview.chromium.org/1912013002
Cr-Commit-Position: refs/heads/master@{#390426}

[modify] https://crrev.com/f24ce736e38fa9b159d59dab44b7cc2c69a67849/third_party/WebKit/Source/platform/fonts/skia/FontCacheSkia.cpp

Status: Fixed
Comment 51 by js...@chromium.org, May 16 2016
Great !!  I'll add all the weights of Roboto and Noto Sans CJK to Chrome OS. 

Blocking: 617281
Sign in to add a comment