Bug 140553 – Apple SD Gothic Neo : {Thin, UltraLight, Light} and {ExtraBold, Heavy} are not distinguished with font-weight in CSS

• Component: Layout and Rendering
• Status: NEW

[Jungshik Shin]

Created attachment 244781 [details]
Apple SD Gothic Neo test page

Mac OS Mountain Lion or later comes with 9 weight instances of Apple SD Gothic Neo, but not all of them are distinguished/accessible when font-weight: [1-9]00 is specified.


* How to reproduce

1. Load the attached html file

* Expected: 
  All 9 weights (font-weight: [1-9]00 ) are distinguishable 

* Actual 
  100 .. 300 all use the same physical font. 
  I suspect 800 and 900 are identical, too

Chrome has the same issue, but Firefox does not. 

The corresponding Chrome/Blink bug is http://code.google.com/p/chromium/issues/detail?id=449256

[Jungshik Shin]

* OS2.usWeight and OS2...bWeight (in OS/2 table) for 9 weight instances of Apple SD Gothic Neo are as following (they're a bit strange. Despite that, somehow Firefox manages to distinguish them all).  

Thin usWeight 300
Thin bWeight 3
UltraLight usWeight 300
UltraLight bWeight 3
Light usWeight 400
Light bWeight 3
Regular usWeight 400
Regular bWeight 3
Medium usWeight 500
Medium bWeight 3
SemiBold usWeight 500
SemiBold bWeight 3
Bold usWeight 600
Bold bWeight 3
ExtraBold usWeight 600
ExtraBold bWeight 3
Heavy usWeight 600
Heavy bWeight 3

[Jungshik Shin]

Created attachment 244784 [details]
Screenshot of Firefox, Chrome and Safari (left to right) rendering the test page

Note that Firefox picks up 9 different weight instances while Safari uses the same weight instance for 100..300 and another instance for weight 800..900. (So does Chrome).

[Jungshik Shin]

The reason Firefox distinguishes all 9 weights (despite the fact that OS/2.usWeightClass values are identical for several of 9 - see comment 2) is that Firefox internally overrides the weight reported by Mac OS X:

Below is from https://bugzilla.mozilla.org/show_bug.cgi?id=1122693#c3

> 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

[Myles C. Maxfield]

This seems like something that https://bugs.webkit.org/show_bug.cgi?id=132159 might fix.

[bert vv]

Created attachment 256672 [details]
screenshot of jsfiddle (normal view on Safari) some font-weights are undistinguishable

[bert vv]

Created attachment 256673 [details]
screenshot of jsfiddle (result view on Safari Firefox and Chrome = ltr) some font-weights are undistinguishable on Safari

Strangely the font-weights in this screenshot (jsfiddle 'embedded result' view) that are undistinguishable on Safari are different than in attachment 256672 [details] (jsfiddle normal view).

[bert vv]

I have the same bug with Roboto font on Safari.
After some testing, I found that the bug only occurs at certain font sizes but there is a catch.


* context: Macbook Pro Retina with OSX Yosemite


* http://jsfiddle.net/8k72a/27/
  jsfiddle 'normal view'
  screenshot: attachment 256672 [details]

1) font-size:1.5em
   the font-weights 100 (Thin) and 300 (Light) are not distinguishable

2) font-size:2em
   every font-weight is perfectly distinguishable

3) font-size:3em
   the font-weights 100 (Thin) and 300 (Light) are not distinguishable



* http://jsfiddle.net/8k72a/27/embedded/result/
  jsfiddle 'embedded result view'
  screenshot: attachment 256673 [details]

1) font-size:1.5em
   every font-weight is perfectly distinguishable

2) font-size:2em
   the font-weights 100 (Thin) and 300 (Light) are not distinguishable


3) font-size:3em
   the font-weights 100 (Thin) and 300 (Light) are not distinguishable


I can personally only reproduce the bug on Safari, not on Firefox (38.0.1) and not on Chrome (43.0.2357.132).


I don't know the technical implicaations of my observations but hopefully it sheds a new light on the issue...

[Yuen Ho Wong]

This is now fixed by bug 132159 right?