Bad font rendering in macOS Monterey on non-English systems
Categories
(Core :: Graphics: Text, defect, P1)
Tracking
()
People
(Reporter: axelsarraille, Assigned: jfkthame)
References
(Blocks 1 open bug)
Details
Attachments
(12 files)
148.12 KB,
image/png
|
Details | |
61.05 KB,
image/png
|
Details | |
108.67 KB,
image/png
|
Details | |
160.90 KB,
image/png
|
Details | |
102.75 KB,
image/png
|
Details | |
697.32 KB,
image/png
|
Details | |
511.36 KB,
image/png
|
Details | |
1.93 MB,
image/png
|
Details | |
94.22 KB,
image/png
|
Details | |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-release+
RyanVM
:
approval-mozilla-esr91+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-release+
RyanVM
:
approval-mozilla-esr91+
|
Details | Review |
48 bytes,
text/x-phabricator-request
|
Details | Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
Get macOS Monterey beta.
Open Firefox.
Actual results:
Font rendering of -apple-system font is cursed. It doesn't render different font weights and letterspacig is wrong. This happens both on the UI and CSS fonts on websites. This happens only on macOS Monterey, not in Big Sur or earlier versions.
Expected results:
Font weight should be properly displayed and letter spacing should be fine, not so stretched.
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
What model of Mac is this on? I believe we have some issues that are specific to the M1 Macs and Monterey.... would be good to confirm exactly what configuration is involved here. (FWIW, the font looks OK on my intel-based MacBook Pro running Monterey beta...)
(In reply to Jonathan Kew (:jfkthame) from comment #4)
What model of Mac is this on? I believe we have some issues that are specific to the M1 Macs and Monterey.... would be good to confirm exactly what configuration is involved here. (FWIW, the font looks OK on my intel-based MacBook Pro running Monterey beta...)
Mine is Intel based, 2019 16-inch Macbook Pro
Assignee | ||
Comment 6•3 years ago
|
||
Interesting - that's exactly what mine is (16" MBPro, 2019), but I'm not seeing the bad system font rendering here. Maybe different OS versions? I'm currently on "12.0 Beta (21A5506j)", but it looks like there's an update available -- I'll try installing that later and see if anything changes.
(In reply to Jonathan Kew (:jfkthame) from comment #6)
Interesting - that's exactly what mine is (16" MBPro, 2019), but I'm not seeing the bad system font rendering here. Maybe different OS versions? I'm currently on "12.0 Beta (21A5506j)", but it looks like there's an update available -- I'll try installing that later and see if anything changes.
I'm on 21A5522h, but have had this bug since beta 1 (didn't report earlier because thought it was a macOS thing, but we're getting close to final :O). Also made a restore and new install of the OS and the bad font rendering is still there. :O
Assignee | ||
Comment 8•3 years ago
|
||
This is really strange -- for comparison, here's how the Firefox menu looks for me.
I have the same issue starting from Beta 1 (right now reproduced on 21A5534d) on MacBook Pro (15-inch, 2016). See attached screenshots from Safari and Firefox 93 for https://sparkmailapp.com/pricing site.
Comment 10•3 years ago
|
||
Safari
Comment 11•3 years ago
|
||
Firefox
Comment 12•3 years ago
|
||
The severity field is not set for this bug.
:lsalzman, could you have a look please?
For more information, please visit auto_nag documentation.
Comment 13•3 years ago
|
||
I do not see this problem on macOS Monterey Beta 21A5552a on an M1 Macbook Pro.
Comment 14•3 years ago
|
||
Updated•3 years ago
|
Reporter | ||
Comment 15•3 years ago
|
||
Still happens on final release of Monterrey, even did a new clean install to check.
Comment 16•3 years ago
|
||
Macbook air 2020 m1, just installed monterey update - can confirm that this terrible font rendering is here. Was using slightly outdated firefox, made sure to update to latest version and still looks terrible. I have m1 iMac whish I didn't update yet, so I can compare two interfaces side by side.
Comment 17•3 years ago
|
||
I get this problem too on Monterey
Comparison of the good font rendering to the bad/condensed rendering
Comment 18•3 years ago
|
||
This is probably the same issue with Thunderbird 91.2.1, too. Bad/condensed font rendering and e.g. unread mails are not highlighted with a bold font.
Comment 19•3 years ago
•
|
||
macOS Monterey (12.0.1) was released yesterday and I can confirm the issue with a 2018 Intel-based MacBook Pro. It's especially noticeable on GitHub (GitHub uses system fonts) where the font is very different compared to Chrome now and where it's no longer possible to see bold fonts (like in mentions). This issue did not exist before the macOS update (macOS 11.6).
And yes, I can also confirm the previous comment: new e-mails in Thunderbird are no longer highlighted with a bold font. It has probably the same cause.
Comment 20•3 years ago
|
||
mhhh. Mozilla and MacOS a ever comlicated thematic..
It is present with Macbook Pro 16 2019 with Firefox 93 on MacOS Monterey 12.0.1
Problem with some Sites and Firefox Fonts itself.
Comment 21•3 years ago
|
||
This is a really serious issue. I still haven't seen it on any of my machines but I will attempt a fresh install today.
Comment 22•3 years ago
|
||
I just upgraded to macOS Monterey and I got the issue. It's pretty terrible. I'm on Firefox Developer Edition 94.0b9 (64 bits), on an i5 Mac mini with an Intel UHD Graphics 630, on macOS 12.0.1 (21A559).
Comment 23•3 years ago
|
||
According to https://bugzilla.mozilla.org/show_bug.cgi?id=1715898#c5 this problem exists only on non English systems. I changed my System Primary Language to English and it works. Then I changed it back to my language this Problem occurs again.
Comment hidden (advocacy, offtopic) |
Comment 25•3 years ago
|
||
[Tracking Requested - why for this release]: Serious quality regression on new version of macOS
Comment 26•3 years ago
|
||
I have set my system language to German and can reproduce the bug now.
Comment 27•3 years ago
|
||
Could this be also considered to be uplifted to ESR? Thunderbird is also affected and would suffer of this problem until next ESR.
Updated•3 years ago
|
Updated•3 years ago
|
Comment 28•3 years ago
|
||
This is really bad on Thunderbird ESR. Not only has the font become incredibly small, but you can't tell unread emails from read ones apart. System language is German.
Comment 29•3 years ago
|
||
This has to do with font variation axis names, and CGFont and CTFont disagreeing about whether the axis names should be localized, it seems. We're not sure yet what exactly changed in macOS Monterey; it's possible that the system font didn't contain localized axis names in previous macOS versions.
Jonathan is working on a patch.
Assignee | ||
Comment 30•3 years ago
|
||
Comment 31•3 years ago
|
||
I checked the font with fonttools
and it does not appear to contain the localized variation axes names.
The localization is happening here using the the default localized name:
* frame #0: 0x00007ff8172670c8 CoreText`CopyDefaultLocalizedName(__CFString const*, __CFString const*, __CFArray const*, __CFString const**)
frame #1: 0x00007ff8172c6b10 CoreText`CopyLocalizedFontNameInternal(CGFont*, CGFontNameTable*, int, __CFArray const*, __CFString const**, __CFString const*) + 1621
frame #2: 0x00007ff8172c6d20 CoreText`CopyLocalizedFontName(CGFontNameTable*, int, __CFArray const*, __CFString const**, __CFString const*) + 34
frame #3: 0x00007ff8173156ea CoreText`TBaseFont::CopyVariationAxesExternal() const + 356
frame #4: 0x00007ff81725ed10 CoreText`CTFontCopyVariationAxes + 39
10.15 doesn't do the localization. I'm not sure about 11
Comment 32•3 years ago
|
||
The same for Cyrillic locale. The default font is too condensed (addressbar, search bar, Github, Wikipedia).
Found another confirmation here: https://www.reddit.com/r/firefox/comments/qfoxx1/macos_monterey_condensed_font_on_firefox_ui/
Updated•3 years ago
|
Assignee | ||
Comment 33•3 years ago
|
||
Depends on D129576
Comment 34•3 years ago
|
||
Pushed by jkew@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/59cc3481c534 [gfx/2d] Get non-localized variation axis names from CoreGraphics in ScaledFontMac, so that we set up the CGFont correctly with variation values. r=jrmuizel https://hg.mozilla.org/integration/autoland/rev/d67d7024d557 [gfx/wr] Fix new_ct_font_with_variations to use non-localized variation axis names from Core Graphics. r=jrmuizel
Assignee | ||
Comment 35•3 years ago
|
||
Comment on attachment 9247883 [details]
Bug 1732629 - [gfx/2d] Get non-localized variation axis names from CoreGraphics in ScaledFontMac, so that we set up the CGFont correctly with variation values. r=jrmuizel,mstange
Beta/Release Uplift Approval Request
- User impact if declined: Bad rendering of the macOS system font (and potentially other variable fonts) for users on macOS 12 Monterey, when the system language is non-English
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: No
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: Run macOS 12.0 Monterey; set the primary system language (in macOS System Preferences / Language & Region panel) to a non-English language; launch Firefox and observe the system font (in menus, tab titles, New Tab page, etc).
- List of other uplifts needed: None
- Risk to taking this patch: Medium
- Why is the change risky/not risky? (and alternatives if risky): This feels a little risky because the macOS APIs involved are not well documented (e.g. the Apple docs don't tell us what axis names Core Graphics expects; nor do they guarantee that Core Graphics and Core Text will expose the axes in the same order, although that seems to hold true in practice).
OTOH, if any of the modified code fails, the result will be no worse than it was without the patches: failure to apply the proper variation settings to some fonts, leading to ugly text rendering.
- String changes made/needed:
Assignee | ||
Updated•3 years ago
|
Comment 36•3 years ago
|
||
Backed out for causing build bustages.
Backout link: https://hg.mozilla.org/integration/autoland/rev/41f479cca4dd6b49d7652d2c4e6638399730da03
Failure log:
https://treeherder.mozilla.org/logviewer?job_id=356199573&repo=autoland&lineNumber=20579
https://treeherder.mozilla.org/logviewer?job_id=356199539&repo=autoland&lineNumber=97
Comment 37•3 years ago
|
||
Pushed by archaeopteryx@coole-files.de: https://hg.mozilla.org/integration/autoland/rev/cc139b6131e4 [gfx/2d] Get non-localized variation axis names from CoreGraphics in ScaledFontMac, so that we set up the CGFont correctly with variation values. r=jrmuizel https://hg.mozilla.org/integration/autoland/rev/bf3b8e872279 [gfx/wr] Fix new_ct_font_with_variations to use non-localized variation axis names from Core Graphics. r=jrmuizel CLOSED TREE
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 38•3 years ago
|
||
Comment 39•3 years ago
|
||
Pushed by archaeopteryx@coole-files.de: https://hg.mozilla.org/integration/autoland/rev/11e1be6ce402 followup, refresh Cargo.lock in wrench. a=wrench-fix CLOSED TREE
Comment 40•3 years ago
•
|
||
We can counteract a big part of the risk with extensive manual testing. We've encountered bugs in this area previously (bug 1201318, bug 1671660, bug 1672842, bug 1675185) so we have some idea of the things that could go wrong.
I think we should do the following checks, on the platforms: macOS 10.12 (Intel), macOS 10.13/10.14 (Intel), macOS 10.15 (Intel), macOS 11 (both Intel and M1), macOS 12 (both Intel and M1), and for both an English and a non-English system language:
- Make sure that the UI fonts look normal
- On 10.13 and and above, make sure variable fonts work:
- The horse should be running: https://www.axis-praxis.org/playground/horse/
- Dragging the slider on https://v-fonts.com/ should affect the text
- On 10.15 and above, dragging the slider on attachment 9185744 [details] should smoothly change the shape of the percent glyph, with no big step between 17 and 18
I've made a spreadsheet to track testing progress: https://docs.google.com/spreadsheets/d/1aa1Biu72rX0bFYnCi3JOB0NzE-GECkP08Qx56bR1mSA/edit#gid=0
Edit: We've done testing on all these platforms now and the results look good.
Comment 41•3 years ago
|
||
Pushed by archaeopteryx@coole-files.de: https://hg.mozilla.org/mozilla-central/rev/0ad5486182ff [gfx/2d] Get non-localized variation axis names from CoreGraphics in ScaledFontMac, so that we set up the CGFont correctly with variation values. r=jrmuizel https://hg.mozilla.org/mozilla-central/rev/b5086513fe50 [gfx/wr] Fix new_ct_font_with_variations to use non-localized variation axis names from Core Graphics. r=jrmuizel a=RyanVM
![]() |
||
Updated•3 years ago
|
Comment 42•3 years ago
|
||
bugherder |
Updated•3 years ago
|
Updated•3 years ago
|
Comment 44•3 years ago
|
||
Comment on attachment 9247883 [details]
Bug 1732629 - [gfx/2d] Get non-localized variation axis names from CoreGraphics in ScaledFontMac, so that we set up the CGFont correctly with variation values. r=jrmuizel,mstange
Not seeing any new macOS crashes on Nightly since this landed. Thanks for all the work verifying this fix yesterday. Approved for 94.0rc2.
Updated•3 years ago
|
Comment 45•3 years ago
|
||
bugherder uplift |
Comment 46•3 years ago
|
||
Comment on attachment 9247883 [details]
Bug 1732629 - [gfx/2d] Get non-localized variation axis names from CoreGraphics in ScaledFontMac, so that we set up the CGFont correctly with variation values. r=jrmuizel,mstange
Approved for 91.3esr.
Updated•3 years ago
|
Comment 47•3 years ago
|
||
bugherder uplift |
Comment 48•3 years ago
|
||
QA - Please expand exploratory testing around this issue/font-rendering in the UI.
Comment 50•3 years ago
|
||
(In reply to Audrey Fischer from comment #48)
QA - Please expand exploratory testing around this issue/font-rendering in the UI.
QA finished the smoke testing around this font rendering problem. Our testing revealed no issue. Details can be found inside this document.
Updated•3 years ago
|
Comment 53•3 years ago
|
||
I can confirm, that the font now renders correctly again in Thunderbird 91 ESR on macOS 12.
Assignee | ||
Comment 54•3 years ago
|
||
Just to fill in a bit more background (thanks to Myles): the breakage here occurred because the Core Text API we're using (CTFontCopyVariationAxes) was fixed this year to return localized variation-axis names (as its documentation has always claimed); as Core Graphics only recognizes the non-localized ones, that led to the issue here.
Apparently there's a private interface CTFontCopyVariationAxesInternal that provides the non-localized names; webkit switched to this in https://trac.webkit.org/changeset/285318/webkit to avoid a performance regression in the case where they don't actually use the names. We could consider going that way as well, to avoid calling both CTFontCopyVariationAxes and CGFontCopyVariationAxes, although as it's not public API there's always the possibility it will break or disappear without notice in some future update.
Description
•