Project: chromium Issues People Development process History Sign in
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
Status: Fixed
Owner:
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment
Font rendering is lighter than Safari / Firefox on OS X El Capitan
Reported by sayem.of...@gmail.com, Oct 10 2015 Back to list
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:
https://en.wikipedia.org/wiki/Main_Page

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 meh...@chromium.org, Oct 11 2015
Labels: -Type-Bug Type-Bug-Regression Needs-Bisect
Comment 2 by meh...@chromium.org, Oct 11 2015
@sayem.office: Is this an El Capitan only issue? Or does it also occur in Yosemite?
@meh...@chromium.org: I'm not sure about Yosemite case.
Cc: kavvaru@chromium.org
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 https://en.wikipedia.org/wiki/Main_Page
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.
541846._win.png
588 KB View Download
541846_Mac.png
717 KB View Download
Comment 5 by tkent@chromium.org, Oct 12 2015
Labels: -Cr-Blink Cr-Blink-Fonts
Comment 6 by e...@chromium.org, Oct 12 2015
Status: WontFix
Working as intended as we have different default font settings.
Comment 7 by pat...@starkast.net, 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 rdb@chromium.org, 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 csilv@chromium.org, Nov 3 2015
Labels: -OS-Windows -OS-Linux
Labels: OS-Linux OS-Windows
Comment 11 Deleted
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).

Yes, I use a non-retina display (iMac (27-inch, Late 2012)).
Comment 14 by e...@chromium.org, Nov 25 2015
Cc: bunge...@chromium.org kojii@chromium.org drott@chromium.org
Status: Available
Cc: e...@chromium.org
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  https://crbug.com/524646  ).

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 mch...@mozilla.com, 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:

https://github.com/google/skia/blob/master/src/ports/SkFontHost_mac.cpp#L776

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 - https://bugzilla.mozilla.org/show_bug.cgi?id=1230366.

Hope this helps!
I'm happy to see this addressed in the latest canary builds, I hope it reaches stable soon :)
Version_49.0.2623.87.png
678 KB View Download
Version_51.0.2692.0_canary.png
690 KB View Download
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).
51.0.2694.1_canary_-_Safari_9.0.3_11601.4.4_-_49.0.2623.87.png
73.4 KB View Download
Cc: -bunge...@chromium.org
Labels: -OS-Linux -OS-Windows Merge-Request-50
Owner: bunge...@chromium.org
Status: Started
This was changed with https://skia.googlesource.com/skia/+/e280d06f3e5fcf12bc34ebabd9bca7965af45112 and https://skia.googlesource.com/skia/+/df801aac5f57c64eb7f081288a299fa3c92cee0d . Requesting permission to merge these two changes into Skia's chrome/m50 branch.
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 tin...@google.com, 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)
Please merge your change to M50 branch 2661 by Friday 5:00 PM PST so we can take it for next week beta.
Labels: Merge-Merged
The Skia commits mentioned in comment 19 have now been cherry-picked into the chrome/m50 branch.
Labels: merge-merged-m50
Labels: -Merge-Approved-50
Per comment #23 and #24, this is already merged to M50. So removing "Merge-Approved-50" label.
Status: Fixed
Sign in to add a comment