v4: min `opsz` == max `opsz`

[rben01]

Describe the bug I am not even sure this is a bug or not, but in the (new and awesome!) v4, opsz 14 (min) appears identical to opsz 32 (max). But 14.1 does look like the opsz of a tiny font.

To Reproduce Steps to reproduce the behavior:

1. Set opsz to 14 (the min value)
2. It looks just like opsz 32 (the max value)

Expected behavior Continuity in opsz, so that 14 is just barely different from 14.1.

Screenshots

opsz 32

opsz 14.whatever

opsz 14.0

Environment

• OS: macOS 14.1
• App that renders the font: Safari
• Version of font: 4.0 (https://rsms.me/inter/lab)

[kenmcd]

The issue is the Safari browser does not support opsz properly. Try it with Chrome or Firefox. They both work properly on Windows 10.

[acordy]

Setting the CSS property text-rendering: optimizeLegibility on either the sample text element or the body (it's inherited) resolves this issue in Safari. Whether it's by design or not, I think I remember reading somewhere that Safari has this property set to optimizeSpeed by default in the user agent, and it looks like a consequence is the effect being observed.

In general, I think this is a good property to explicitly set to optimizeLegibility on any site, since it hints to the browser and rendering engine to not sacrifice typographic integrity over what I assume is in 2023 a trivial performance hit.

In any case, adding this to the https://rsms.me/inter site would resolve this issue and possibly avoid confusion for others.

[rben01]

On second thought I'm not even sure this is a bug at all — at least, not with either Safari or Inter, but rather, perhaps, with https://rsms.me/inter/lab/. I believe the cause is that setting opsz to 14 simply removes the corresponding query parameter from the Inter Lab URL, which, evidently, falls back to the default opsz of 32.

[acordy]

@kenmcd I don't know if you saw my previous comment, this might be a change to make to the site to resolve the issue on Safari.

@rben01 Without a query parameter in the URL, the optical size is still being set via font-variation-settings: "wght" 400, "opsz" 14, so the optical size is explicitly set to 14. You can see this in dev tools. The issue really does appear to be the lack of the text-rendering property, which when set to optimizeLegibility resolves the issue.

[alexschcom]

The initial comment by @rben01, shows the font size is set to 32px, which would cause the font to automatically apply the corresponding optical size. If you change the font size to 14px (and leave the opsz param at 14px) you'll see that it actually does work (look at the opened aperture of the lowercase "a", for example). As you scale the font size up, you'll see the optical size adjust with it. To disable this behavior, you can set font-optical-sizing to none.

[rsms]

Strangely I can't reproduce in Safari. What you are seeing might be some new behavior in Safari on macOS 14 (which I don't have.)

Since the opsz value is set explicitly via font-variation-settings: "opsz" 14, a compliant web browser should not attempt to match opsz to font size. If Safari is doing that it is a bug and will likely be fixed in an upcoming release.