New issue
Advanced search Search tips

Issue 856713 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug



Sign in to add a comment

faux-bolding is hard to tell from regular for some fonts (e.g. Noto Naskh Arabic UI served as web font)

Project Member Reported by js...@chromium.org, Jun 26 2018

Issue description

Coming from an internal bug: b/70506041 (comment 44). 

It seems that faux-bolding (synthetic bolding on the fly) is not 'bold enough' on macOS for some fonts (e.g. Noto Naskh Arabic UI ). It's rather hard to distinguish bold from regular when a native bold is absent and faux bolding is used.

For the same font, Chrome on Windows and Linux do not have this issue. 

Safari's faux-bold seems to be slightly bolder than that of Chrome. 

A test case: 

Only one weight (400) is loaded from the GWF: 
http://jungshik.github.io/cr/bugs/boldtest/faux.html . 

Two weights (400, 700) are loaded from the GWF:
http://jungshik.github.io/cr/bugs/boldtest/native.html 

I have two fonts (Noto Naskh Arabic UI for Arabic and Lato for Latin) in the test file. 


 

Comment 1 by js...@chromium.org, Jun 26 2018

Description: Show this description

Comment 2 by js...@chromium.org, Jun 26 2018

Description: Show this description

Comment 3 by js...@chromium.org, Jun 26 2018

Components: Blink>Fonts
This is true, but will probably go away. The issue has been that when 'subpixel smoothing' is enabled (lcd rendering) CoreGraphics fake-bolds the outline internally before drawing it. CoreGraphics won't give us this fake-bolded outline (and the amount of fake bolding varies between versions and requested sizes), so when we fake bold we're fake bolding the original outline. As a result these look similar. It appears that with macOS 14 subpixel smoothing is going to be removed and (it is assumed) this issue will evaporate. As a result this is unlikely to be given high priority since this is a long outstanding issue which will probably solve itself.

Comment 5 by js...@chromium.org, Jun 26 2018

Thanks a lot for the explanation. The amount of fake-bolding seems to depend also on the font (as well as size). 

I'm attaching a screenshot.

Left:  Safari
Middle: Firefox
Right: Chrome (it shows both 'Noto Naskh Arabic UI' and 'Lato'). Lato seems to get bolder 'fake bold' than Noto Naskh Arabic UI (the outline of Naskh Arabic perhaps gives little room for error so that I guess fake-bolding is rather conservative here ??). 



Screen Shot 2018-06-26 at 10.55.25 AM.png
1.0 MB View Download

Comment 6 Deleted

http://www.google.com/search?hl=ar (or fa or ur) now uses 'Noto Naskh Arabic UI' as a web font. 

They don't fetch the bold version of the font, but relies on faux-bolding for bold. So, it'd be nice if we could do something about it. Well, bold in Arabic is not a 'native concept', I guess. An alternative would be for Google search to come up with another way to emphasize in Arabic.  

Sign in to add a comment