1856035 - Variable fonts render in maximum optical size regardless of opsz axis value

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect)

Description

[Dan Burzo]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

Here’s a sample variable font featuring an optical size axis: https://ateliertriay.github.io/bricolage/

Actual results:

Using the Fonts panel in the FF Dev Tools you are able to change the opsz axis value in the [12-96] range. Observe that changing the optical size only alters the spacing, but the glyphs outlines correspond to the opsz: 96 design space coordinates.

I believe this is a regression in Firefox 118.

Expected results:

Altering the opsz axis value should change the glyph outlines.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Text' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Jonathan Kew [:jfkthame]]

Dan, what version of macOS are you on? This works as expected for me (the glyph outlines change as well as the spacing) in both FF 118.0.1 and Nightly (120.0a1), on macOS 13.4. But I'm suspicious something may have changed in Sonoma...

Comment 3

[Dan Burzo]

Jonathan, I am indeed on macOS Sonoma (M1 processor).

Comment 4

[Jonathan Kew [:jfkthame]]

Thanks for confirming this. I suspect this may be the same underlying issue as bug 1851033, where the rendering of the system font (which I believe uses optical sizing) is slightly "off" -- if we're failing to set the proper 'opsz' value, that could explain the system font issue too.

Comment 5

[Dan Burzo]

Yes, I was going to suggest the connection as well. It does make sense — the larger opsz would mean more slender glyphs set much wider. However, I had experienced (and logged) an "excessive spacing" issue (bug 1721612) with the default macOS font prior to Sonoma, which occurred even as opsz was working properly in Firefox.

Comment 6

[Jonathan Kew [:jfkthame]]

OK, I just updated my (Intel) MacBook to Sonoma, and this issue now reproduces for me as well. I'll try to investigate what's going on....

Comment 7

[Cartesius68]

Just confirming that not a regression in 118, even ESR affected on MacOS Sonoma.

Comment 8

[Markus Stange [:mstange]]

(Marking this bug as confirmed until Jonathan decides which way he wants to do the dup'ing)

Comment 9

[Olli Meier]

We have the same issues with firefox 118 and fonts we produced (including a opsz axis). It worked before firefox 118 and it still works with Chrome and Safari. So, something has changed with 118 and it seems not to be the right approach. Happy to help if needed/possible. I am sure, we (Fontwerk) can give you some variable fonts with opsz axis for testing. Or simply download the trial fonts here:
Font family Case: https://fontwerk.com/fonts/case#buying-options
Font family Nice: https://fontwerk.com/fonts/nice-superfamily#buying-options

Comment 10

[Olli Meier]

Click 'Trial' and you can download them for free. It's a subset of the original fonts, but should be enough for testing.

Comment 11

[Jonathan Kew [:jfkthame]]

Yeah, this is not a recent Firefox regression, or at least that's not the whole story.... having updated to Sonoma (on an Intel-based Mac) I can reproduce the same problem with much earlier versions than 118 -- at least as far back as 96.0a1 from ~2 years ago.

It may well be (I suspect from various reports) that whether the failure happens is related to more than one factor: the macOS version, the Firefox version, the CPU architecture (because macOS APIs may behave differently even for nominally the same OS version), and the SDK version targeted by the Firefox build (which can also alter how a given API behaves).

So.... not simply a new regression, but it's definitely becoming much more widely noticed with the release of Sonoma, so we really need to get to the bottom of this.

Initial testing indicates that variation axes seem to work fine except for opsz, where we appear to be ending up with a fixed opsz that is derived from the device pixel size of the font (not the CSS px or pt size), which -- especially on a Retina screen, where device-pixel size is twice the CSS px value -- will tend to be the maximum. Moreover, once we've instantiated the font with a given opsz setting, that "sticks" even if the font size is reduced such that even the device-pixel size is within or below the opsz range.

Not yet sure where in the process the "real" opsz that we want to apply is getting lost....

Comment 12

[Brunno Pleffken [:bpleffken]]

(In reply to Olli Meier from comment #9)

We have the same issues with firefox 118 and fonts we produced (including a opsz axis). It worked before firefox 118 and it still works with Chrome and Safari. So, something has changed with 118 and it seems not to be the right approach.

Worth to mention that this is not a recent issue. Firefox had problems with font rendering on Apple Silicon M1/M2 Macs (bug 1721612) since 2 years ago (Firefox 90), and these bugs are still open — the macOS Sonoma has only made the situation worse across all platforms. Since Chromium browsers never had these issues, it seems like the way Firefox handles font rendering on macOS needs to be looked at.

Definitely not a simple regression.

Comment 13

[Jonathan Kew [:jfkthame]]

Beginning to explore the example here (comment 0) with the Bricolage Grotesque font, I'm seeing some strange entries in the font's fvar table and I think these may be one source of problems. I've opened https://github.com/ateliertriay/bricolage/issues/9 to bring this to the designer's attention.

That's not the whole issue as far as Gecko is concerned; even after stripping out the bad named-instance entries, I'm still seeing the same broken behavior (although the Core Graphics font instances we create are at least less confused). Further investigation continues....

Comment 14

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1856035 - Rework the management of font variation settings across CoreGraphics and CoreText font instances.

It appears that when a Core Text font is instantiated from a CGFont or from a font descriptor,
its optical-size setting now always gets assigned according to the font size being created,
overriding any 'opsz' variation that was already specified on the CGFont or the CTFontDescriptor.
(This seems to be a behavior change compared to older macOS versions.)

To get the desired 'opsz' setting on the Core Text font, it seems to be necessary to use
CTFontCreateCopyWithAttributes to get a modified copy of an already-existing CTFont.

Comment 15

[Jonathan Kew [:jfkthame]]

This seems to work well for me in local testing. Let's see how it fares on tryserver, before asking for review.... https://treeherder.mozilla.org/jobs?repo=try&revision=0bc6ea6561c91d8e9fcfa45bc191d4dbd00b6c37

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/57fec34232bd
Rework the management of font variation settings across CoreGraphics and CoreText font instances. r=gfx-reviewers,lsalzman

Comment 18

[Jonathan Kew [:jfkthame]]

[Tracking Requested - why for this release]:
Now that macOS Sonoma is released, a rapidly-increasing number of users will be experiencing this, and the resulting text rendering can be quite bad (see also the dup'd bug 1851033). So I think once the fix is verified we should get it into the hands of users without waiting to ride the full train.

Comment 19

[Pascal Chevrel:pascalc]

This needs to land now on mozilla-central, be verified by QA tomorrow morning so as that I can uplift this to the planned dot release that we build tomorrow and ship on Tuesday.

Comment 20

[Jonathan Kew [:jfkthame]]

Requesting QA verification -- only required on macOS, as the files touched by the patch are Mac-specific, and not even compiled on other platforms.

We should test (a) that the rendering on Sonoma is fixed (e.g. with the example from comment 0);
and (b) that variable fonts still work as expected on earlier versions of macOS.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

We probably want to uplift this to Beta ahead of tomorrow's b7 build also?

Comment 22

[Jonathan Kew [:jfkthame]]

That'd be awesome, yeah. The patch is currently on autoland; I'll go ahead and nominate it for both beta and release, in hopes that QA can verify it on Nightly ASAP tomorrow.

(mozilla-release will need a rebased patch, as the CoreTextFontList refactoring that landed in bug 1170986 makes it not apply cleanly; it's functionally unchanged, just enough changes in the context to prevent a clean transplant.)

Comment 23

[Jonathan Kew [:jfkthame]]

Comment on attachment 9357254 [details]
Bug 1856035 - Rework the management of font variation settings across CoreGraphics and CoreText font instances.

Beta/Release Uplift Approval Request

• User impact if declined: Bad rendering of variable fonts (incl. macOS system font) on Sonoma, esp. on Retina screens.
• 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: Load example page from comment 0; use Inspector to vary the Optical Size axis, and confirm that glyph shapes vary appropriately.
  (Also see dup'd bug 1851033.)
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): This changes the APIs we're using to manage font variations across the macOS frameworks; I believe the new approach uses better-supported, more reliable APIs, but it does need to be tested across all currently-supported OS versions.
  Once QA has verified that variable fonts still work across all supported versions, I would consider the risk "low", as overall this is a cleanup/simplification of the code.
• String changes made/needed:
• Is Android affected?: No

Comment 24

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1856035 - [rebased to mozilla-release] Rework the management of font variation settings across CoreGraphics and CoreText font instances. r=lsalzman

Comment 25

[Jonathan Kew [:jfkthame]]

Comment on attachment 9357305 [details]
Bug 1856035 - [rebased to mozilla-release] Rework the management of font variation settings across CoreGraphics and CoreText font instances. r=lsalzman

Just moving the approval-mozilla-release flag to the rebased version of the patch.

Comment 27

[Jonathan Kew [:jfkthame]]

Try run of mozilla-release with rebased patch: https://treeherder.mozilla.org/jobs?repo=try&revision=4cdd560e94fbadd2bb0256619412584b22dbdd25

Comment 28

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/57fec34232bd

Comment 29

[Donal Meehan [:dmeehan]]

Comment on attachment 9357254 [details]
Bug 1856035 - Rework the management of font variation settings across CoreGraphics and CoreText font instances.

Approved for 119.0b7

Comment 30

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/2c502d3a5967

Comment 31

[Jonathan Kew [:jfkthame]]

It looks like this may have broken the behavior for macOS 12 on an M1 machine, according to QA testing. So we can't go ahead with uplift right now, further testing/fixing will be needed.

Comment 32

[Brindusa Tot, Desktop QA]

Attachment: Screen Recording 2023-10-09 at 5.30.59 PM.mov

Comment 33

[Brindusa Tot, Desktop QA]

Verified on macOS 12 M1 with the latest Nightly 120 - build Id 20231009093538, and it seems that the fix affects the fonts. Please seen the screen record attached.

Comment 34

[Pascal Chevrel:pascalc]

Comment on attachment 9357305 [details]
Bug 1856035 - [rebased to mozilla-release] Rework the management of font variation settings across CoreGraphics and CoreText font instances. r=lsalzman

Not taking the uplift in our dot release as it caused regressions, thanks!

Comment 35

[Virgil Sangerean]

Hello.
Our investigation shows that despite the fix works for macOS 14 and macOS14 ARM, there is a regression present on macOS11, macOS12 and MacOS12 ARM.

It must be noted that macOS 10.15 , macOS13 and macOS13 ARM are not affected by this regression.

Thank you!

Comment 36

[Jonathan Kew [:jfkthame]]

Donal, you might want to back this out of beta for now, given that it appears to cause a regression on macOS 11 and 12.

I'm intending to back out the patch from central, and then plan to re-land in a modified form after (hopefully) getting QA to test a try build across multiple versions.

Comment 37

[Donal Meehan [:dmeehan]]

I'll back this out in the next beta push.
Keeping the ni until then.

Comment 38

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1856035 - Backed out changeset 57fec34232bd for regression behavior on macOS 11 and 12.

Not sure why the new implementation doesn't work on older OS versions,
but these APIs are inadequately documented and liable to change behavior
between releases. So just go with what works, as shown by testing.

Comment 39

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1856035 - Merge implementations of CreateCTFontFromCGFontWithVariations from gfxMacFont.cpp and 2d/ScaledFontMac.cpp (no change in behavior). r=#gfx-reviewers

This should not change behavior, it just merges the two versions of
CreateCTFontFromCGFontWithVariations to simplify maintenance.

Depends on D190500

Comment 40

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1856035 - Rework the management of font variation settings across CoreGraphics and CoreText font instances, on macOS 13 and later only. r=#gfx-reviewers

The new approach works on Ventura and Sonoma, but appears to regress behavior on some
earlier releases, so put it behind a runtime version check.

Once we no longer support pre-macOS 13 versions, we can simplify this.

Depends on D190501

Comment 41

[Jonathan Kew [:jfkthame]]

I have Lando'd the backout here, to fix the macOS 11/12 regression on Nightly; we can try again with the new patches once they have been reviewed & tested.

Comment 42

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/fa96537be56b
Backed out changeset 57fec34232bd for regression behavior on macOS 11 and 12.

Comment 43

[Martin Blom]

Just wanted to mention that my newspaper issue (in bug 1851033) disappeared with the release of Nightly 120.0a1 (2023-10-09). Many thanks.

Comment 44

[Jonathan Kew [:jfkthame]]

(In reply to Martin Blom from comment #43)

Just wanted to mention that my newspaper issue (in bug 1851033) disappeared with the release of Nightly 120.0a1 (2023-10-09). Many thanks.

Unfortunately, your issue will be back in today's Nightly, as that fix had to be reverted. I'll be trying again shortly, and hope the fix "sticks" this time!

Comment 45

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/31c8123d186c
Merge implementations of CreateCTFontFromCGFontWithVariations from gfxMacFont.cpp and 2d/ScaledFontMac.cpp (no change in behavior). r=gfx-reviewers,lsalzman
https://hg.mozilla.org/integration/autoland/rev/46b3ed462290
Rework the management of font variation settings across CoreGraphics and CoreText font instances, on macOS 13 and later only. r=gfx-reviewers,lsalzman

Comment 46

[Jack Roberts]

Not sure if the patch is active in the latest Nightly as Martin's comment would suggest, but I'm seeing no change in -apple-system font spacing on an M1 running macOS 13.6. Still appears with excessive letter spacing as demonstrated in bug 1721612

Comment 47

[Jonathan Kew [:jfkthame]]

(In reply to Jack Roberts from comment #46)

Not sure if the patch is active in the latest Nightly as Martin's comment would suggest, but I'm seeing no change in -apple-system font spacing on an M1 running macOS 13.6. Still appears with excessive letter spacing as demonstrated in bug 1721612

Hmm, curious; bug 1721612 comment 23 seemed to indicate it was fixed. But there may be more factors in play.

To confirm, what does about:buildconfig show as "Built from https://hg.mozilla.org/mozilla-central/rev/.....`?

Assuming the (new) fix here sticks, and resolves the general optical-size failure this bug describes, we should follow up any remaining issues with the Sonoma system font in a separate bug, to better keep track of each issue.

Comment 48

[Jonathan Kew [:jfkthame]]

Brindusa, Virgil, & team: thank you so much for the QA efforts yesterday, that was really valuable.

Once the revised patches (just pushed to autoland) appear in Nightly, can we please repeat the testing across all supported macOS versions (for both x64 and M1 machines), to check for any breakage with the new fix. Thanks!

Donal, FYI: as soon the revised fix is in Nightly and QA has taken a look, I'll plan to nominate for uplift; hoping we can get this fixed in time for your next beta.

Comment 49

[Jack Roberts]

(In reply to Jonathan Kew [:jfkthame] from comment #47)

(In reply to Jack Roberts from comment #46)

Not sure if the patch is active in the latest Nightly as Martin's comment would suggest, but I'm seeing no change in -apple-system font spacing on an M1 running macOS 13.6. Still appears with excessive letter spacing as demonstrated in bug 1721612

Hmm, curious; bug 1721612 comment 23 seemed to indicate it was fixed. But there may be more factors in play.

To confirm, what does about:buildconfig show as "Built from https://hg.mozilla.org/mozilla-central/rev/.....`?

Assuming the (new) fix here sticks, and resolves the general optical-size failure this bug describes, we should follow up any remaining issues with the Sonoma system font in a separate bug, to better keep track of each issue.

about:buildconfig is showing Built from https://hg.mozilla.org/mozilla-central/rev/6404412771ea15ef1c719a515dd1369360fb8d4d

I think this bug may be specifically affecting the system font, because I haven't seen any other fonts affected like this. It's been this way on my machine for about two years now. It also disappears when running under Rosetta.

It seems to be exactly 0.3px wider than Safari and Chrome, from what I can tell

Comment 50

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/fa96537be56b

Comment 51

[Jonathan Kew [:jfkthame]]

Oops, I should have tagged this as leave-open; that wasn't the fix, just the backout. Re-opening, until the new fix (comment 45) merges to central.

Comment 52

[Brunno Pleffken [:bpleffken]]

(In reply to Jack Roberts from comment #46)

Not sure if the patch is active in the latest Nightly as Martin's comment would suggest, but I'm seeing no change in -apple-system font spacing on an M1 running macOS 13.6. Still appears with excessive letter spacing as demonstrated in bug 1721612

Confirming this (on M1 Pro macOS 14).

The latest patch may have resolved the extremely grotesque appearance of the fonts on macOS Sonoma, but I still notice excessive letter spacing when compared to Safari and Chromium browsers, exactly as described in bug 1721612. So, this bug is still not closed.

Comment 53

[Jonathan Kew [:jfkthame]]

OK, thanks for the reports. I've re-opened bug 1721612 to follow up on the Sonoma system font spacing issue; let's wait for the patch here to be safely landed, and then follow up there with the remaining concern.

Comment 54

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox118 (release). However, the bug still has low severity.

:bhood, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 55

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-beta/rev/e5262149857c4ed47ea596f1a5c8a1f0ca7c4639
Backed out changeset 2c502d3a5967 (Bug 1856035) for regression behavior on macOS 11 and 12.

Comment 56

[Cristina Horotan [:chorotan]]

https://hg.mozilla.org/mozilla-central/rev/31c8123d186c
https://hg.mozilla.org/mozilla-central/rev/46b3ed462290

Comment 57

[Virgil Sangerean]

Hello.
We have successfully verified the fix on the latest version of FF Nightly from the 11th of October.
We understand that there are some related issues regarding fonts and spacing for MacOS Sonoma and other versions, so for this we have created a document with the OS versions we tested on along with the 3 scenarios we covered. Document can be found here: "https://docs.google.com/spreadsheets/d/1QjLmYFicAHj9FX4VmgzWkxDWVdW88mZK6ObVu9s8Glg/edit#gid=0"

Please let us know if there is any other investigation or validation that we can help with.
Thank you!

Comment 58

[Donal Meehan [:dmeehan]]

:jfkthame based on comment 57, is this safe for an uplift request consideration?
Fx119 goes to RC next week, the last beta 119.0b9 builds on Friday

Comment 59

[Jonathan Kew [:jfkthame]]

Comment on attachment 9357493 [details]
Bug 1856035 - Rework the management of font variation settings across CoreGraphics and CoreText font instances, on macOS 13 and later only. r=#gfx-reviewers

Beta/Release Uplift Approval Request

• User impact if declined: Bad rendering of variable fonts with optical sizing on recent macOS versions
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Runtime version check limits the new implementation to macOS 13 and later, to minimize the risk of regressions on older OS versions.
• String changes made/needed:
• Is Android affected?: No

Comment 60

[Donal Meehan [:dmeehan]]

Comment on attachment 9357492 [details]
Bug 1856035 - Merge implementations of CreateCTFontFromCGFontWithVariations from gfxMacFont.cpp and 2d/ScaledFontMac.cpp (no change in behavior). r=#gfx-reviewers

Approved for 119.0b9

Comment 61

[Donal Meehan [:dmeehan]]

Comment on attachment 9357493 [details]
Bug 1856035 - Rework the management of font variation settings across CoreGraphics and CoreText font instances, on macOS 13 and later only. r=#gfx-reviewers

Approved for 119.0b9

Comment 62

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/dab4725c55b6
https://hg.mozilla.org/releases/mozilla-beta/rev/c1fdb5720f2a

Comment 64

[Ryan VanderMeulen [:RyanVM]]

Do we need to get this to ESR115 also?

Comment 65

[Virgil Sangerean]

Issue has been verified on 119.0b9 version of Firefox.

Details about the OS version this has been tested in can be found here: https://docs.google.com/spreadsheets/d/1QjLmYFicAHj9FX4VmgzWkxDWVdW88mZK6ObVu9s8Glg/edit#gid=0

Comment 66

[Jonathan Kew [:jfkthame]]

Comment on attachment 9357492 [details]
Bug 1856035 - Merge implementations of CreateCTFontFromCGFontWithVariations from gfxMacFont.cpp and 2d/ScaledFontMac.cpp (no change in behavior). r=#gfx-reviewers

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: With macOS Sonoma in public release, an increasing number of users will be running into this as they upgrade older OS versions
• User impact if declined: macOS changes in recent release cause variable fonts to render incorrectly; effect can vary from slightly-wrong spacing to badly misrendered (e.g. overlapping glyphs), depending on the font involved
• Fix Landed on Version: 119
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Change in behavior is only applied on recent macOS versions (runtime check), to avoid regressing behavior for older releases. Verified in Nightly & Beta by QA across multiple OS versions/both architectures.

Comment 67

[Donal Meehan [:dmeehan]]

:jfkthame there are merge conflicts in the following:
gfx/thebes/gfxMacFont.cpp
gfx/thebes/gfxMacFont.h
Could you attach a patch rebased onto esr115?

Comment 68

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1856035 - Merge implementations of CreateCTFontFromCGFontWithVariations from gfxMacFont.cpp and 2d/ScaledFontMac.cpp (no change in behavior). [rebased to esr115]

Comment 69

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1856035 - Rework the management of font variation settings across CoreGraphics and CoreText font instances, on macOS 13 and later only. [rebased to esr115]

Depends on D191123

Comment 70

[Donal Meehan [:dmeehan]]

Comment on attachment 9357492 [details]
Bug 1856035 - Merge implementations of CreateCTFontFromCGFontWithVariations from gfxMacFont.cpp and 2d/ScaledFontMac.cpp (no change in behavior). r=#gfx-reviewers

Approved for 115.4esr.

Comment 71

[Donal Meehan [:dmeehan]]

Comment on attachment 9357493 [details]
Bug 1856035 - Rework the management of font variation settings across CoreGraphics and CoreText font instances, on macOS 13 and later only. r=#gfx-reviewers

Approved for 115.4esr.

Comment 72

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/c7056110034d
https://hg.mozilla.org/releases/mozilla-esr115/rev/3184dc5f0841

Comment 73

[Virgil Sangerean]

Verified also on RC1 115.4.0esr-build1.
Please check the following table for more details: https://docs.google.com/spreadsheets/d/1QjLmYFicAHj9FX4VmgzWkxDWVdW88mZK6ObVu9s8Glg/edit#gid=0.