Bug 227353 – Font optical sizing is broken when set to default value

• Status: NEW
• Component: CSS

[Ernst]

Created attachment 432167 [details]
test case

When setting the `opsz` axis in a variable font to the default value, it gets sized incorrectly.

Attached is an example where Source Sans (with its default opsz value of 20) is used as a variable font, and for testing purposes the optical size is set to increasing values. Notice the wrong jump when set to 20, which is the default (nearby values like 19.999 and 20.001 work correctly). Firefox and Chrome work correctly.

[Ernst]

Created attachment 432168 [details]
screenshot documenting the issue

[Radar WebKit Bug Importer]

<rdar://problem/80026031>

[Sam Sneddon [:gsnedders]]

This appears not to reproduce in macOS 12 (but does reproduce with STP 128 on macOS 11).

[Ahmad Saleem]

@Myles - will it be fixed by your recent work around this?

[Ahmad Saleem]

Safari 16.5.1 seems to have fixed it but Safari Technology Preview 174 and WebKit ToT seems to have it as broken. Confused!

[alan]

This has regressed at 264750@main

[Stephen Nixon]

Confirming this is still an issue in Safari Version 17.3.1 (19617.2.4.11.12) and Safari Tech Preview Release 195 (Safari 17.4, WebKit 19619.1.15.0.1).

This bug is super disruptive in fonts that have wider opsz ranges than Source Serif. A major benefit of optical sizing is that it can be automatic, but WebKit is holding it back across browsers. Please consider prioritizing this issue. 🙏

[Alexey Proskuryakov]

Thank you for the report and for the follow-up!

The issue is well understood thank to a great test case, however could you please add some more color for prioritization? Does this affect any live websites? If not, what specifically is being held back without possibility of a workaround?

[Stephen Nixon]

Hi Alexey, thanks for taking a look and for asking about it!

Good question, a bit challenging to answer. The biggest impact is one that is subtle but important: because opsz doesn’t work well in WebKit, it prevents the wider adoption of variable fonts with opsz axes, making it hard to point to specific examples that are broken due to this bug (because few large websites are going to ship broken typography to everyone with an iPhone). 

So, for now, the easiest examples to point to of the issue occurring in production are font-focused websites. 

On v-fonts, you can see three good examples of this problem occuring. Load any of these pages in Safari, look carefully at the default style that loads, with the default opsz, and then notice how that has a big jump when the opsz slider is moved at all. This is because these fonts have an opsz optimized for text (as a safe fallback style for e.g. older browsers or devices), but Safari loads them in rendered at their max opsz.

- https://v-fonts.com/fonts/roboto-flex
- https://v-fonts.com/fonts/helvetica-now-variable
- https://v-fonts.com/fonts/adapter

If any of these relatively major releases is used to build a major website, the developer would probably be forced to use static fonts instead of the variable fonts. And, if variable fonts are a good thing for rich web typography (which they are), then this issue is holding that back.

It is also currently occurring to me on my own font website, where my variable font preview should load in with its default opsz of 16, but instead shows up at the max size – and then jumps if the Optical Size slider is moved a bit.

- https://www.arrowtype.com/kyrios

However, as important as this issue is to fix to improve the readability of web typography, an even more vital issue is that Webkit (and Chromium) is failing to properly render Slant and Italic axes in variable fonts. That means that every font which can have a variable axis for obliques/italics must be split into two separate fonts – one for upright styles, and the other for italic styles – which partly defeats the benefit of variable fonts on the web. This bug is filed here:

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

Of course, the best thing would be for both bugs to be fixed, but broken italics are a bigger problem than optical sizes.

Thanks for your time here! Please let us know if any other questions arise.

[Stephen Nixon]

Small update here: since my previous comment, I have made an update of the font family Kyrios, making that example from my prior comment no longer a good example.

As a workaround to this issue, I set the default Optical Size to be the maximum value. This is not a great thing, because now the font menus in macOS apps have an extra "Display Regular" instance, when they should just have instances describing weights, without opsz labels involved. Additionally, for users viewing the font on older systems that don’t render variable font axes, they will see the low-readability Display styles of that default instance. In that way, I am forced to break the OpenType’s suggested default for the axis:

> A value in the range 10 to 16 is recommended for typical text settings.

https://learn.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_opsz

...but the workaround is better than having a font broken for all WebKit users.

Hopefully, in the future, this axis will be fully supported, and such choices won’t have to be made by font makers.

[Stephen Nixon]

Testing this again today, I’ve found a second condition required for this bug to happen:

The other axes must also be set to default.

That is, if a variable font has both wght and opsz axes, this bug happens when weight is at default, and opsz is at default. If the weight is changed (say, to wght=650 when the default is wght=900), opsz is rendered correctly.

Also, just wanted to say that Ernst made a wonderful test case page. Very helpful for checking back on this!

[Stephen Nixon]

Also, I do think the nature of this bug has changed slightly...

Previously, when a font was set to the default opsz, it would render as the max opsz. (If I am remembering correctly.)

Now (as tested in Safari Version 17.4), when a font is set to its default opsz, it instead renders with the opsz set to its current font size.

Another way to say this: `font-variation-settings` is ineffective for opsz when it is set to a font’s default axis values. It should force a particular variation setting for opsz, but instead it acts like `font-optical-sizing: auto;` for that one value.

This may not matter in many cases, but for example, it could be a problem if a website tried to set large headlines in a small opsz value, for aesthetic or high-legibility purposes. It also may disrupt "type testers" on font foundry websites. As a good example, check out Source Serif 4 Variable on Adobe Fonts:

https://fonts.adobe.com/fonts/source-serif-4-variable?vf-axes=opsz%2C20%2Cwght%2C400&vf-font-size=100&vf-font=SourceSerif4Variable-Italic

When the sample is set to its default opsz=20, it appears as opsz=60, as that is closest to its current font size (100px). If that opsz axis is moved at all, it jumps to the correct value on either size of opsz=20. This is basically just showing the same thing as the initial test case in this issue, but it may be a clearer example, and it is a live website that is representative of a place the bug is a genuine problem.