Bug 258944 – Optical Size (opsz) axis is handled very inconsistently in variable fonts

• Component: Text
• Status: NEW

[Stephen Nixon]

Created attachment 466956 [details]
Reproduction repo

In Safari Technology Preview (Release 173 (Safari 17.0, WebKit 18616.1.20.2)):
- In a variable font with an Optical Size (`opsz`) axis and Weight (`wght`) axis
- If the `wght` and `opsz` axes are at their defaults (often but not always with `wght=400` and `opsz` somewhere between about `8` and `20`)

...The `opsz` that gets *rendered* is the font’s maximum `opsz`. 

This is tested in Roboto Flex, Roboto Serif, Newsreader, Fraunces, and other variable fonts with `wght` & `opsz` axes.

Reproduction repo: https://github.com/arrowtype/safari-opsz-test

Reproduction site: https://arrowtype.github.io/safari-opsz-test

![Safari Optical Size issue, Fraunces](images/safari-issue-opsz-fraunces.png)
![Safari Optical Size issue, Roboto Flex](images/safari-issue-opsz-robotoflex.png)
![Safari Optical Size issue, Newsreader](images/safari-issue-opsz-newsreader.png)

Another simple way to test this is to load such font into [Wakamai Fondue](https://wakamaifondue.com/beta/). It has type testers that are set to the font’s defaults. Slide the sliders around a little, and notice how the rendered font will “jump” in style at certain values.

Please note: in the current main Safari, there are other `opsz` inconsistencies. For example, if you go to a font’s max `opsz`, the rendered font weight will suddenly be the min `wght`. So, please test for that while fixing this, and don’t e.g. simply revert changes to opsz handling (not that I think you would do so, but there have been problems here for awhile, so please be careful but also quick, if possible, in addressing it).

Thanks so much for all your work here!

[Stephen Nixon]

Created attachment 466957 [details]
Screenshot of an example of the issue

Here is one of several tests of the issue, showing that the rendered opsz is incorrect when opsz and wght axes are at their defaults.

[Stephen Nixon]

I don’t think I can edit a previous comment, so to add detail to this:

> in the current main Safari, there are other `opsz` inconsistencies

There, I am referring to my experience in Version 16.1 (18614.2.9.1.12).

Additionally, I am viewing this on an M1 Mac, Ventura 13.0 (22A380)

[Ahmad Saleem]

Created attachment 466958 [details]
WebKit ToT Screenshot (for Reference)

[Stephen Nixon]

Ah, seeing Ahmad’s latest screenshot makes me realize I had slightly misdiagnosed the error.

When the opsz is specifically set to its default, the text isn’t rended as only the *maximum* opsz. Instead, it is rendered with opsz as the current px size – it is basically acting with "auto" opsz forced, even when font-variation-settings should be overriding that behavior.

[Stephen Nixon]

...and the above true in both Safari Technology Preview (Release 173 (Safari 17.0), and also appears to be happening in Ahmad’s screenshot of WebKit ToT. But yes, that is why it doesn’t match the max opsz in Ahmad’s screenshot. And indeed, if I scale my browser window down, the fact that the text is sized with vw units means that a smaller window starts to change what auto opsz is (wrongly) applied to that text that has been assigned the default opsz value.

[Stephen Nixon]

Created attachment 466982 [details]
Updated reproduction repo

[Stephen Nixon]

I noticed that my tests weren't very predictable, because font sizing with using the vw (viewport width) unit. I have since updated example fonts to be 64px, which better shows that the default opsz gets ignored and the font is set to the current px size, despite font-variation-settings being used.

[Radar WebKit Bug Importer]

<rdar://problem/112219672>