Variable fonts with slant axis not slanting correctly for font-style positive values
Categories
(Core :: Layout: Text and Fonts, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox74 | --- | fixed |
People
(Reporter: arrowtypeco, Assigned: jfkthame)
References
()
Details
Attachments
(5 files)
Screen Shot 2020-01-28 at 2.56.52 PM.png
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
Steps to reproduce:
See test webpage at https://arrowtype.github.io/vf-slnt-test/firefox-slnt.html
See also https://bugs.webkit.org/show_bug.cgi?id=200369 and https://bugs.chromium.org/p/chromium/issues/detail?id=859869 for related bugs in Chromium and WebKit (if it's useful to you).
Actual results:
When a variable font is declared with the correct CSS @font-face value of font-style: oblique 0deg 10deg;, Firefox does not allow a user to correctly apply italic slant, except via the low-level method of font-variation-settings.
It does not work to use font-style: oblique, font-style: oblique 10deg, font-style: italic, or <i> to apply italic styles from the slant axis.
There is one way to apply the Slant axis through the font-style property, but it is incorrectly programmed and does not accurately follow the CSS spec. See test page linked to above for more details.
Expected results:
Variable fonts with negative, clockwise-sloping Slant axis values should be possible to control via CSS with a positive value of oblique (CSS Spec, font-style: https://drafts.csswg.org/css-fonts-4/#font-style-prop). For example, CSS such as font-style: oblique 10deg; should result in clockwise-slanting text when the font has a slnt axis with values 0 to -10 (as required by the OpenType spec: “a typical, right-leaning oblique design will have a negative slant value,” https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_slnt).
Additionally, font-style:italic should activate the Slant axis if an Italic axis is not present. Per the CSS Spec: “Italic: Matches against a font that is labeled as an italic face, or an oblique face if one does not exist ...For TrueType / OpenType fonts that use variations, the slnt variation is used to implement oblique values.”
|
||
Updated•5 years ago
|
|
Assignee | |
Comment 2•5 years ago
|
||
The 'slnt' axis vs CSS font-style:oblique mismatch seems a bit unfortunate, but I guess we're stuck with it because the OpenType and CSS conventions for which way angles are measured are each (separately, and oppositely) pretty well established.
So this does look like a legitimate bug; we need to invert the sign of the angle in appropriate places when mapping between the CSS and OT worlds. I'll try to look into this; we can probably fix fairly easily (I hope).
|
|
Assignee | |
Updated•5 years ago
|
|
Reporter | |
Comment 3•5 years ago
|
||
Awesome, thanks Gingerbread Man, Sotaro and Jonathan!
|
|
Assignee | |
Comment 4•5 years ago
|
||
I wonder if there are existing (incorrect) testcases this will break... let's see what tryserver thinks:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d1912edbd2248c915c4f5cc99a99ac81aa016051
|
|
Assignee | |
Comment 5•5 years ago
|
||
Looks promising. Reporter, could you try this test build and confirm if it behaves more like you expect? Thanks!
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 6•5 years ago
|
||
Ah, one more thing we need to fix: the DevTools font inspector isn't aware of the sign reversal, so it still doesn't behave correctly even in the patched build.
This may be a bit tricky; we'll need to make a choice whether the slider in the Inspector works directly in terms of the 'slnt' axis (so from -10 to 0 in the example here) or in terms of the CSS font-style:oblique value (so from 0 to 10). Not sure which is better... either way seems arguably "correct", but also potentially confusing. Razvan, WDYT?
|
|
Assignee | |
Comment 7•5 years ago
|
||
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 8•5 years ago
|
||
Depends on D61228
|
|
Reporter | |
Comment 9•5 years ago
|
||
we'll need to make a choice whether the slider in the Inspector works directly in terms of the 'slnt' axis (so from -10 to 0 in the example here) or in terms of the CSS font-style:oblique value (so from 0 to 10). Not sure which is better... either way seems arguably "correct", but also potentially confusing.
This is a bit of a tough call. Those sliders control font-variation-settings, as far as I’m aware ... is that correct?
If so, in my view, the slider should almost certainly go from -10 to 0, because:
- font-variation-settings: 'slnt' -10; is still correct to access the low-level, OpenType font value for a 10deg clockwise slant
- All design tools I have seen handle the slnt axis as -10 to 0 (e.g. Adobe tools, Sketch)
- Variable font test sites like WakamaiFondue.com and axis-praxis.org also handle it this way
However, I agree that the mismatch is somewhat confusing. If there could be some kind of note that this controls the values in font-feature-settings but font-style: oblique still uses clockwise degree values, it might help users to understand the difference. Then again, I suspect that the majority of users will only ever use font-style:italic, and just accept the full slant.
|
|
Reporter | |
Comment 10•5 years ago
|
||
Current varfont slider for slnt not applying correctly
- the sliders show font axes, e.g.
wght,slnt,ital,MONO, etc - the
slntslider is correctly going from -15 to 0, left to right - the
slntslider is INCORRECTLY applying a negative value tofont-style: oblique Xdeg. Instead, the value must be inverted so that a full slant (in this font, Recursive) isfont-style: oblique 15deg
|
|
Assignee | |
Comment 11•5 years ago
|
||
(In reply to arrowtypeco from comment #10)
Current varfont slider for slnt not applying correctly
- the sliders show font axes, e.g.
wght,slnt,ital,MONO, etc- the
slntslider is correctly going from -15 to 0, left to right- the
slntslider is INCORRECTLY applying a negative value tofont-style: oblique Xdeg. Instead, the value must be inverted so that a full slant (in this font, Recursive) isfont-style: oblique 15deg
Yes, that was still the behavior in the Inspector with the initial patch I tried, as that was before I thought about the devtools part of it. With the current patch up for review, the slider should correctly set the font-style property using the inverted sign from the 'slnt' axis.
(I've started new builds with the latest patch at https://treeherder.mozilla.org/#/jobs?repo=try&revision=b0c1b8ff92ccaff9e8f6f4e6f74bdd0cde5b0c69, but it'll be a while before the macOS and Windows builds are ready.)
|
|
Reporter | |
Comment 12•5 years ago
|
||
Awesome, thanks for your quick work on this! Understandable that it will take some time. Just wanted to make sure you had the details needed. Cheers!
|
|
Assignee | |
Comment 13•5 years ago
|
||
Oops - sorry, I tagged the wrong Razvan here for any feedback on the devtools side of this.
|
|
Assignee | |
Comment 14•5 years ago
|
||
Reporter, if you'd like to try the newest test build to check whether it behaves as you expect, you can find the macOS download at https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HIZseU1QR7SGt_2PVQCEAw/runs/1/artifacts/public/build/target.dmg. Thanks for your input here!
|
||
Comment 15•5 years ago
|
||
|
|
Reporter | |
Comment 18•5 years ago
|
||
Reporter, if you'd like to try the newest test build to check whether it behaves as you expect
@jfkthame the build at https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/HIZseU1QR7SGt_2PVQCEAw/runs/1/artifacts/public/build/target.dmg seems to work perfectly!
Thanks so much for your quick action on this. :)
|
|
Reporter | |
Comment 19•5 years ago
|
||
@jfkthame I've found one remaining issue in your latest build:
In dev tools, When I update the font-style property in the CSS column, the value of the Slant axis in the Fonts inspector doesn't update. By contrast, if I change the font-weight value, the Weight axis does update.
This is a very small bug, and I'd hate for it to hold up the improvements. But, it might be a final remaining issue with negative values, and is hopefully similarly quick to correct.
Thanks again for your great work on this!
|
||
Comment 20•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/719878745b59
https://hg.mozilla.org/mozilla-central/rev/74a6c4e121f0
|
|
Assignee | |
Comment 21•5 years ago
|
||
(In reply to Stephen Nixon from comment #19)
@jfkthame I've found one remaining issue in your latest build:
In dev tools, When I update the
font-styleproperty in the CSS column, the value of the Slant axis in the Fonts inspector doesn't update. By contrast, if I change thefont-weightvalue, the Weight axis does update.This is a very small bug, and I'd hate for it to hold up the improvements. But, it might be a final remaining issue with negative values, and is hopefully similarly quick to correct.
I see what you mean. Checking the code for the Inspector, it looks like it has simply never been hooked up in this direction. I'll file a separate bug to follow up on this.
|
||
Comment 23•5 years ago
|
||
Thank you Stephen for the very detailed bug report and Jonathan for quickly addressing this.
(In reply to Stephen Nixon from comment #9)
This is a bit of a tough call. Those sliders control font-variation-settings, as far as I’m aware ... is that correct?
The sliders corresponding to variable font axes will write the value as follows:
- if it's a registered axis, write to the corresponding font CSS property (ex:
wght->font-weight) only if the axis is not declared in afont-variation-settingsvalue anywhere in the cascade for the selected node. Otherwise, update thefont-variation-settingsvalue. - if it's a custom variation axis, always write to
font-variation-settings.
If so, in my view, the slider should almost certainly go from -10 to 0, because:
I agree with your assessment. One of the goals of the Fonts panel for variable fonts is to expose axes and their corresponding value ranges so users don't have to resort to the font documentation all the time. Keeping the range accurate seems the right approach.
With regards to the bug in DevTools, I see Jonathan already filed the fix in bug 1613162 and that looks good to me. Thank you, Jonathan!
Description
•