Bug 261293 - Errors with oblique/slnt angle values for variable fonts
Summary: Errors with oblique/slnt angle values for variable fonts
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: Safari 16
Hardware: Mac (Apple Silicon) macOS 13
: P2 Normal
Assignee: Nobody
URL:
Keywords: BrowserCompat, InRadar
Depends on:
Blocks:
 
Reported: 2023-09-07 14:35 PDT by Nick Sherman
Modified: 2023-09-20 00:25 PDT (History)
3 users (show)

See Also:


Attachments
Oblique angle test with a variable font shown in Safari 16.6 on the left and Firefox 117.0 on the right (453.41 KB, image/png)
2023-09-07 14:35 PDT, Nick Sherman
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Sherman 2023-09-07 14:35:12 PDT
Created attachment 467590 [details]
Oblique angle test with a variable font shown in Safari 16.6 on the left and Firefox 117.0 on the right

There are currently several issues related to the handling of oblique angles and the corresponding `slnt` axis in variable fonts.

1) When an oblique angle is specified via the `font-style` property, the text is slanted in the opposite direction it should be. This is likely the result of a 1:1 mapping between the angle in degrees and the resulting value of the `slnt` axis, instead of an inverted mapping. The `slnt` axis in variable fonts is set so positive numbers correspond to counter-clockwise slanting, and negative numbers to clockwise slanting, but the opposite is true for how oblique angles are set with degrees in CSS. In other words, `15deg` in CSS should correspond to a `slnt` value of -15.

There are a couple strange exceptions to this behavior that are wrong in other ways but I haven't figured out the logic (see the 45deg and -45deg lines in the sample page linked below and/or attached screenshots).

2) This may be related to the above, but setting a default `oblique` value (without an angle) results in no visible angle being applied. The default should be 14deg (i.e. a `slnt` value of -14).

3) It seems that if a `slnt` axis value is set directly via the `font-variation-settings` property, and it exceeds the supported range of the variable font, the value is ignored altogether. It should instead be clamped to the closest value the font supports.

Here is a test page on CodePen to see these issues:
https://codepen.io/NickSherman/pen/QWzdaZM

There is also a comparison screenshot attached here of Safari 16.6 vs Firefox 117.0.


References:
https://drafts.csswg.org/css-fonts-4/#font-style-prop
https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_slnt
Comment 1 Radar WebKit Bug Importer 2023-09-14 14:36:16 PDT
<rdar://problem/115519700>