Roboto and Noto Sans CJK (Source Han Sans) : font-weight: [100,200,300] are not distinguished

NEW
Unassigned

Status

()

defect
P3
normal
4 years ago
2 years ago

People

(Reporter: jshin1987, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

Attachments

(1 attachment)

Reporter

Description

4 years ago
Roboto and Noto Sans CJK / Source Han Sans come in 6 or 7 weights. 

Roboto: Thin, Light, Regular, Medium, Bold, Black
Noto Sans CJK/Source Han Sans : Thin, Light, DemiLight, Regular, Medium, Bold, Black

However, Firefox on Mac OS X always picks Roboto Thin and Noto Sans CJK DemiLight for font-weight: [100,200,300] in CSS. When DemiLight instance is uninstalled, Firefox always pick Noto Sans CJK Light for f-w=100..300.  

* How to reproduce:

1. Install Roboto ( http://www.google.com/design/spec/style/typography.html ) 
2. Go to http://goo.gl/EGsg0s
3. Compare 3 columns - Local Fonts, 'Web Font', 'Roboto+<weight>'
4. Examine which font is actually used in DOM Inspector - Fonts tab for 'Local font' column (each weight)

* Expected:
Local font' column is identical to 'Web Font'' column in terms of weight variations. 
For weights 100 and 300, 'Roboto Thin' and 'Roboto Light' are used (Dom Inspector - Fonts tab). 

* Actual
 font-weight=100 and font-weight=300 use the same font (Roboto Light) in the first case (Local font). That is, there's no distinction between font-weight=100 and font-weight=300 even though there are two separate weight instances installed (Roboto Light.ttf and Rohoto Thin.ttf)

* Additional information. 
1. In OS/2 table of the "thin" instance of the two familes, '250' (instead of 100) is used for usWeight. However, using '100' didn't make any difference. 
2.
Noto Sans CJK {KR,SC,TC,JP} and Noto Sans {KR,JP,SC,TC} has exactly the same issue (when DemiLight instance is NOT installed).  When DemiLight (OS2.usWeight=350) is present, font-weight=100..300 all uses DemiLight.

See https://code.google.com/p/noto/issues/detail?id=199 

3. Safari and Chrome have the same issue. 

4. Safari and Chrome picks up Roboto Thin when 'font-family' is explicitly set to 'Roboto Thin' ('Roboto-<weight> column). OTOH, Firefox does not recognize font-family with weight explicitl such as 'Roboto Thin'. (I do NOT think of this as a bug).

5. With the newest version of fontconfig installed, Firefox on Linux can distinguish all weights in Roboto and Noto Sans CJK / Source Han Sans when font-weight: [134579]00 is used. 

6. The corresponding Chrome bug is http://crbug.com/449310

7. Firefox distinguishes all 9 weights of Apple SD Gothic Neo (installed by default since Mountain Lion) while Chrome and Safari cannot. See http://crbug.com/449256
Reporter

Comment 2

4 years ago
See https://code.google.com/p/noto/issues/detail?id=199 for more details on Noto Sans CJK (screenshots, test procedure, etc).
This is related to two things (1) the use of skewed weight scales by Adobe and other font vendors to avoid synthetic bolding under GDI and (2) underlying problems with the way OSX reports font weights. I think the first problem will require some OpenType spec solution (some sort of flag to indicate skewed values for the OS2 weightClass values? an additional weight field such as 'weightClassNonSkewed'?). The second one requires fixing by Apple, plain and simple.

[1] http://lists.w3.org/Archives/Public/www-style/2015Jan/0076.html

> 7. Firefox distinguishes all 9 weights of Apple SD Gothic Neo (installed by default 
> since Mountain Lion) while Chrome and Safari cannot. See http://crbug.com/449256

This is because Firefox includes explicit overrides for several of the font families on OSX that are incorrect or not reported well by the underlying platform API's. For *lots* of details, see bug 931426. In short, it's a clusterf**k. The "solution" on that bug was to create a bunch of prefs to explicitly override font weight values.

Example:

  font.weight-override.AppleSDGothicNeo-Thin 100

So one solution would be to simply do something similar for Noto Sans CJK fonts:

  font.weight-override.NotoSansCJK-Thin 100

The suffix here is the postscript name of the specific font.

Not saying this is a great way to do this but will work.
Whiteboard: [gfx-noted]
Reporter

Comment 4

4 years ago
> This is related to two things (1) the use of skewed weight scales by Adobe and other 
> font vendors to avoid synthetic bolding under GDI and

That's initially what I thought (see my original bug report at https://code.google.com/p/noto/issues/detail?id=199, which is about setting OS/2.usWeight to 100 for Thin in Noto Sans CJK ) , but even when I set OS/2.usWeightClass to 100 for Thin, I still have exactly the same problem in all three browsers including Firefox. 

> This is because Firefox includes explicit overrides for several of the font families on OSX

Yeah, I suspected that Firefox did that.
(In reply to Jungshik Shin from comment #4)
> > This is related to two things (1) the use of skewed weight scales by Adobe and other 
> > font vendors to avoid synthetic bolding under GDI and
> 
> That's initially what I thought (see my original bug report at
> https://code.google.com/p/noto/issues/detail?id=199, which is about setting
> OS/2.usWeight to 100 for Thin in Noto Sans CJK ) , but even when I set
> OS/2.usWeightClass to 100 for Thin, I still have exactly the same problem in
> all three browsers including Firefox. 

This is the (2) part of the problem I mentioned in comment 3. ;)

If you look through some of the dumps of font weight data on bug 931426 you'll see this clearly; there are cases where the same usWeight value will map to different appKit/CoreText weight values. The style name also affects the weight value under OSX, although I haven't worked out the precise logic. Style names like "Thin", "UltraLight", etc. *can* affect the weight value as opposed to more generic names like "W1", "W2", "W3" etc. often used by Japanese font families.
Reporter

Comment 6

4 years ago
Thank you for the reply, John. 

I also filed a bug against Webkit ( https://bugs.webkit.org/show_bug.cgi?id=140553 ) and it's suggested that using CTFontCreateForCSS might solve the problem  ( https://bugs.webkit.org/show_bug.cgi?id=132159 )

Comment 7

2 years ago
I can confirm this is now happening for San Francisco and PingFang supplied by MacOS since El Captian. Apple has since fixed this issue on Safari. Any update on this?
You need to log in before you can comment on or make changes to this bug.