Skip to content
This repository has been archived by the owner on Jan 25, 2023. It is now read-only.

CJK: Browsers on Mac OS X cannot distinguish between Thin and Light #199

Closed
GoogleCodeExporter opened this issue Jun 8, 2015 · 14 comments
Closed

CJK: Browsers on Mac OS X cannot distinguish between Thin and Light #199

GoogleCodeExporter opened this issue Jun 8, 2015 · 14 comments
Labels
Type-Defect

Comments

@GoogleCodeExporter
Copy link 

With fsWeight set to 250 for Thin, Chrome, Firefox and Safari all use Light for 
font-weight:100


Test page: 
https://deb53d85a427140a6e10ee61e1ceb3408c8407f2.googledrive.com/host/0B153_ao11
p4QR2s3RWRXMUhJa1U/notosanscjk_weights.html

In  column 2 (local font), weight=100 and weight=300 are identical on Chrome, 
Firefox and Safari. Both rows use 'Light' (weight=300). 

In column 3 (Web Font), they're different. weight=100 is thin while weight=300 
is light. 

All these browsers should pick up a font with the weight larger than or equal 
to the requested weight (i.e. when 100 is requested, 250 should be picked 
instead of 300), but they do not. Apparently, they look for weights in 
multiples of 100. 


Behdad is working with CSS WG on this issue. I'll file a bug against 
Chrome/Blink, Webkit and Firefox. 


BTW, if there's ExtraLight (with weight set to 270) between Thin and Light, 
doing the above wouldn't distinguish between Thin (requested CSS weight 100) 
and ExtraLight (requested CSS weight 200) because both will end up being mapped 
to Thin (fsWeight=250). I began to wonder if we'd better do the right thing 
(using fsWeight=100 for Thin) and have a separate Windows build.

Original issue reported on code.google.com by jshin@chromium.org on 12 Nov 2014 at 11:36
@GoogleCodeExporter
Copy link
Author

Original comment by jungs...@google.com on 12 Nov 2014 at 11:36

  • Changed state: New

@GoogleCodeExporter
Copy link
Author

Original comment by jungs...@google.com on 12 Nov 2014 at 11:37

  • Changed title: *CJK: Browsers on Mac OS X cannot distinguish between Thin and Light *

@GoogleCodeExporter
Copy link
Author 

I did a new experiment and the result is different from what I wrote above and 
is still NOT what we expect to see. I couldn't reproduce what I wrote above.  

* Procedure
  1. Change the weights of Noto Sans CJK {JP,KR,TC,SC} Thin to {240,200,170,130}
  2. Change the weight of Noto Sans KR Thin 100
  3. Install all 7 weights of Noto Sans JP (v 1.002), Noto Sans CJK {JP,KR,TC,SC} and Noto Sans KR with Thin's weight changes per #1 and #2
  4. Install all 7 weights of 20140609 version of Noto Sans Simplified Chinese (weight is 100 for Thin)
  5. Restart (not necessary, but just in case) Firefox, Chrome and Safari 
  6. View the attached HTML page in all three browsers; 
      - It has 8 columns for testing Noto Sans CJK/JP/KR?SC fonts with different OS2.usWeights for Thin (250, 240, 200, 170, 130, 100, 100). 
      - The last column is Apple SD Gothic Neo that comes in 9 weights
      - It has 9 rows from font-weight in CSS ranging from 100 to 900. 
  7. Remove DemiLight instances of all Noto Sans* fonts.
  8. Repeat 5 and 6

Results:

1. In step 6, all three browsers in all columns (except for the last which is 
Apple SD Gothic Neo) use 'DemiLight' for font-weight={100,200,300}. 


2. In step 8 (with DemiLight removed), for font-weight={100,200,300) are 
rendered with 'Light'. 

3. The last column (Apple SD Gothic Neo) : Firefox on the one hand and 
Chrome/Safari on the other hand behave differently. 

a. Firefox : The last column (Apple SD Gothic Neo) is rendered in 9 distinct 
weight instances of Apple SD Gothic Neo

b. Chrome and Safari : It appears that font-weight={100,200,300} are NOT 
distinguishable. It appears that 'Apple SD Gothic Neo Light' is used for 
font-weight={100,200,300}. The reason I'm not sure is Chrome's DOM Inspector 
does not give the full font name (including weight) in Computed section for 
this font (it does give the full font names for Noto Sans fonts). 

-----------------

Given that all the browsers behave identically (except for Apple SD Gothic 
Neo), something in CoreText is at play here and we have to talk to Apple to 
figure out what's going on. 


BTW, TextEdit can distinguish all 7 weights (it does not use numeric weight. I 
can simply choose 'weight' in the menu).

Original comment by jshin@chromium.org on 14 Jan 2015 at 1:22

Attachments:

@GoogleCodeExporter
Copy link
Author 

I'll attach the screenshots from step 8 tomorrow for the record.

Original comment by jshin@chromium.org on 14 Jan 2015 at 1:23

@GoogleCodeExporter
Copy link
Author 

Apple SD Gothic Neo {Thin...Heavy} have very interesting values for 
OS2.usWeight and OS2.bWeight (panose) :

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

The fact that Firefox picks each of them in order for CSS 
font-weight=[100..900] suggests that Firefox may do some hard-coding (with 
subfamily names in the name table).

Original comment by jshin@chromium.org on 14 Jan 2015 at 6:10

@GoogleCodeExporter
Copy link
Author 

With DemiLight removed, Light is used for font-weight={100,200,300} in all 
three browsers regardless of what OS2.usWeight value is used for Thin. Attached 
is a screenshot taken with Chrome.

Original comment by jshin@chromium.org on 15 Jan 2015 at 1:23

Attachments:

@GoogleCodeExporter
Copy link
Author 

Blink (Chrome) bug : http://code.google.com/p/chromium/issues/detail?id=449256
Firefox bug : https://bugzilla.mozilla.org/show_bug.cgi?id=1122693

I'll file a bug against Webkit, too.

Original comment by jshin@chromium.org on 16 Jan 2015 at 7:55

@GoogleCodeExporter
Copy link
Author 

Oops: Chrome bug is https://code.google.com/p/chromium/issues/detail?id=449310

Original comment by jshin@chromium.org on 16 Jan 2015 at 7:56

@GoogleCodeExporter
Copy link
Author 

CSS-style list discussion: 
http://lists.w3.org/Archives/Public/www-style/2015Jan/0076.html

Original comment by jshin@chromium.org on 20 Jan 2015 at 7:55

@GoogleCodeExporter
Copy link
Author 

In Firefox bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1122693), John 
Dagget provided more details : 

https://bugzilla.mozilla.org/show_bug.cgi?id=1122693#c5
https://bugzilla.mozilla.org/show_bug.cgi?id=1122693#c3
https://bugzilla.mozilla.org/show_bug.cgi?id=931426

In short, Mozilla has to override the weight value reported by AppKit/CoreText 
by adding a preference for Apple SD Gothic Neo (which also has a similar issue) 
:

  font.weight-override.AppleSDGothicNeo-Thin 100

Original comment by jshin@chromium.org on 27 Jan 2015 at 12:14

@GoogleCodeExporter
Copy link
Author 

Webkig bug for Apple SD Gothic Neo : 
https://bugs.webkit.org/show_bug.cgi?id=140553
where it's suggested that using  CTFontCreateForCSS 
( https://bugs.webkit.org/show_bug.cgi?id=132159 ) might solve the problem (not 
yet confirmed)

Original comment by jshin@chromium.org on 27 Jan 2015 at 12:33

@GoogleCodeExporter
Copy link
Author 

What I can try is to write a stand-alone program to see what weight is reported 
by AppKit/CoreText for Noto Sans CJK and Roboto. 

Note to myself: see 
http://lxr.mozilla.org/mozilla-central/source/gfx/thebes/gfxMacPlatformFontList.
mm#434

Original comment by jshin@chromium.org on 27 Jan 2015 at 6:42

@GoogleCodeExporter
Copy link
Author

Original comment by stua...@google.com on 4 Feb 2015 at 2:18

@behdad
Copy link
Contributor

behdad commented Jun 8, 2015

cc @roozbehp @kenlunde @behdad

@oliviazhu oliviazhu mentioned this issue Jun 10, 2015
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Type-Defect
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@behdad @jungshik @oliviazhu @GoogleCodeExporter