New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 14 users

Issue metadata

Status: Fixed
Closed: Apr 2016
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug

Sign in to add a comment

Issue 541846: Font rendering is lighter than Safari / Firefox on OS X El Capitan

Reported by, Oct 10 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.115 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Load any webpage
2. Load the same webpage on Safari / Firefox
3. Compare font rendering by placing 2 browsers window side-by-side.

What is the expected behavior?
Font rendering should be better & same as all other apps render fonts on Mac OS X.

What went wrong?
Font rendering is lighter than native Mac OS X font rendering.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? Yes Until Chromium Version 40.0.2214.115 (64-bit)

Does this work in other browsers? Yes 

Chrome version: 45.0.2454.101  Channel: stable
OS Version: OS X 10.11.0
Flash Version: Shockwave Flash 19.0 r0
font render - chrome vs safari - mac os x.png
880 KB View Download

Comment 1 by, Oct 11 2015

Labels: -Type-Bug Type-Bug-Regression Needs-Bisect

Comment 2 by, Oct 11 2015 Is this an El Capitan only issue? Or does it also occur in Yosemite?

Comment 3 by, Oct 11 2015 I'm not sure about Yosemite case.

Comment 4 by, Oct 12 2015

Labels: -Type-Bug-Regression -Needs-Bisect Type-Bug OS-Windows OS-Linux M-48
Status: Untriaged
Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 using chrome latest stable 45.0.2454.101 with the below steps

1. Go to URL
2.Observe the light color font compared to firefox

This issue is reproducible on windows and Linux but unable to reproduce the issue on Mac 10.10.5 Yosemite (Please find the attached screen shot).
This is non regression issue observed from M30.Marking it as Untriaged.
588 KB View Download
717 KB View Download

Comment 5 by, Oct 12 2015

Labels: -Cr-Blink Cr-Blink-Fonts

Comment 6 by, Oct 12 2015

Status: WontFix
Working as intended as we have different default font settings.

Comment 7 by, Oct 30 2015

I'm using Chrome 46.0.2490.80 (64-bit). I went from Yosemite to El Capitan today and I noticed this directly. This was not the case on Yosemite.

Is it possible to change the font settings in Chrome to match the way it looks in Safari? I have looked under "Settings -> Web content -> Customize fonts...", but it looks like the only thing I can tweak is the font size.

Comment 8 by, Nov 3 2015

Status: Unconfirmed
Has anyone tested this on a non-retina display? On an internal Google mailing list the complaints are all for non-retina displays.

Comment 9 by, Nov 3 2015

Labels: -OS-Windows -OS-Linux

Comment 10 by, Nov 3 2015

Labels: OS-Linux OS-Windows

Comment 11 Deleted

Comment 12 by, Nov 3 2015

I recommend that this issue be confined to the specific issue that was reported, which is font rendering in OS X 10.11 El Capitan. (This may be related to the issue in #4, but it may be better to handle that in a separate issue).

The key points of the original issue:

1) Font rendering appears different (lighter) on OS X 10.11 El Capitan, than OS X 10.10 Yosemite.
2) The problem may be specific to non-retina screens (or just more observable).

Comment 13 by, Nov 7 2015

Yes, I use a non-retina display (iMac (27-inch, Late 2012)).

Comment 14 by, Nov 25 2015

Status: Available

Comment 15 by, Nov 25 2015

As far as the El Capitan vs. Yosemite issue, there is one change which may be affecting this. The newer OSX is more aggressively using size as a font selector. For example, requesting an NSFont of size 20 may resolve to a completely different font (and by this I do mean a completely different font file) than the exact same request but for size 19. The larger sizes are lighter weight and the smaller sizes are heavier. This is just a heavy handed way of trying to force optical sizing.

When Blink goes and creates its NSFonts, it seems to request size 20 (though I'm not sure where) so it gets the lighter 'header' optical weight. It then asks Skia to draw using this NSFont. Skia then goes out of its way to draw with exactly this font's data no matter the size, because the font returned at 20 and that at 19 may have different glyph mappings, and Blink isn't prepared for that (nor is anyone else really, see  ).

Blink could request NSFonts at a smaller size (getting the 'text' weight) but then the larger sizes would look too heavy. I know of no means to query where such breaks will be, if there were Blink could treat each of these size ranges as a separate platform font.

Comment 16 by, Jan 12 2016

Hi all,

I didn't realize this was related to only El Capitan. It can confirm it is mostly noticeable on a non-retina display. I was investigating this in Gecko and pinned it down to at least here:

The crux seems to be previously, Skia created fonts with CTFontCreateCopyWithAttributes with a text size of 1 and a scale transform. Now it's created with CTFontCreateWithGraphicsFont with a specified text size. I did some digging in Gecko here -

Hope this helps!

Comment 17 by, Mar 30 2016

I'm happy to see this addressed in the latest canary builds, I hope it reaches stable soon :)
678 KB View Download
690 KB View Download

Comment 18 by, Mar 30 2016

Doesn't look exactly as Safari, but it sure is an improvement. In the screenshot from left to right: Chrome 51.0.2694.1 canary, Safari_9.0.3 (11601.4.4) and Chrome 49.0.2623.87. On my non-retina iMac (27-inch, Late 2012).
73.4 KB View Download

Comment 19 by, Mar 30 2016

Labels: -OS-Linux -OS-Windows Merge-Request-50
Status: Started (was: Available)
This was changed with and . Requesting permission to merge these two changes into Skia's chrome/m50 branch.

Comment 20 by, Mar 31 2016

Thank you all for working on this issue. Excited to see improvements in stable version soon. Also wishes for Chrome team to match Safari grade text rendering, in near future.

Comment 21 by, Mar 31 2016

Labels: -Merge-Request-50 Merge-Approved-50 Hotlist-Merge-Approved
Your change meets the bar and is auto-approved for M50 (branch: 2661)

Comment 22 by, Mar 31 2016

Please merge your change to M50 branch 2661 by Friday 5:00 PM PST so we can take it for next week beta.

Comment 23 by, Mar 31 2016

Labels: Merge-Merged
The Skia commits mentioned in comment 19 have now been cherry-picked into the chrome/m50 branch.

Comment 24 by, Mar 31 2016

Labels: merge-merged-m50

Comment 25 by, Mar 31 2016

Labels: -Merge-Approved-50
Per comment #23 and #24, this is already merged to M50. So removing "Merge-Approved-50" label.

Comment 26 by, Apr 21 2016

Status: Fixed (was: Started)

Sign in to add a comment