[Webkit-unassigned] [Bug 261293] New: Errors with oblique/slnt angle values for variable fonts

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=261293

            Bug ID: 261293
           Summary: Errors with oblique/slnt angle values for variable
                    fonts
           Product: WebKit
           Version: Safari 16
          Hardware: Mac (Apple Silicon)
                OS: macOS 13
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Text
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: nick at nicksherman.com
                CC: mmaxfield at apple.com

Created attachment 467590

  --> https://bugs.webkit.org/attachment.cgi?id=467590&action=review

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230907/2379f6c5/attachment-0001.htm>