Closed Bug 1478720 Opened 3 years ago Closed 3 years ago
Fonts not reacting to font-variation-settings values on OS X
This bug was tested on the latest Nightly and latest OS X version. STR: 1. Visit https://typetools.typenetwork.com/ 2. Click on the element labeled with `H1` 3. Check "View all axis" in the left sidebar 4. Play around with the transparent / opaque axis (e.g. move first y transparent, then y opaque) for a little bit ER: the fonts should adjust according to the settings AR: the fonts adjust for the first slider, but stop working when moving the second slider This behavior can also be tested with the devtools font editor or by setting the `font-variation-settings` manually.
Martin, could you please try the build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=0f8568c8bf06701a154ced1e8bf0809501321cab&selectedJob=190889590 and confirm whether the issue can still be reproduced? Thanks!
Looks good! I cannot reproduce the issue anymore :-)
I don't entirely understand what's going wrong here, but it seems to be related to the 'opsz' axis and the tendency of Core Text to get confused when the page explicitly sets an 'opsz' value that matches the font's default. We worked around this in bug 1457417, but apparently with the Amstelvar font we're still dangerously close to it; increasing the fudge amount to 0.01, which is still way below what should be a perceptible optical-size difference with any reasonable font, seems to avoid the problem.
Attachment #8996002 - Flags: review?(lsalzman)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Attachment #8996002 - Flags: review?(lsalzman) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/9068ee10e910 Increase the fractional adjustment applied to 'opsz' on macOS to avoid using the font's default setting, which may be mishandled by Core Text. r=lsalzman
Comment on attachment 8996002 [details] [diff] [review] Increase the fractional adjustment applied to 'opsz' on macOS to avoid using the font's default setting, which may be mishandled by Core Text Approval Request Comment [Feature/Bug causing the regression]: variable fonts (not a regression) [User impact if declined]: some variable fonts may render incorrectly [Is this code covered by automated tests?]: no (version of macOS in CI infrastructure is too old) [Has the fix been verified in Nightly?]: yes [Needs manual test from QE? If yes, steps to reproduce]: yes; STR in comment 0 [List of other uplifts needed for the feature/fix]: none [Is the change risky?]: no [Why is the change risky/not risky?]: minor adjustment to the "fudge factor" we use to work around a Core Text quirk [String changes made/needed]: none
Attachment #8996002 - Flags: approval-mozilla-beta?
[Tracking Requested - why for this release]: We're shipping Variable Fonts as one of the high-profile new features in Fx62; it would be unfortunate to ship with this as a visible bug on demo pages.
Comment on attachment 8996002 [details] [diff] [review] Increase the fractional adjustment applied to 'opsz' on macOS to avoid using the font's default setting, which may be mishandled by Core Text Fix for a bug in a new feature for 62. Let's uplift for beta 15.
Attachment #8996002 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
I successfully reproduced this issue on Firefox Beta 62.0b13 under macOS 10.13 using the STR from Comment 0. The issue is no longer reproducible on Firefox Beta 62.0b15 and latest Nightly 63.0a1 (2018-08-06), under macOS 10.13.
You need to log in before you can comment on or make changes to this bug.