W3C home > Mailing lists > Public > public-css-archive@w3.org > June 2020

Re: [csswg-drafts] [css-fonts] Proposal to extend CSS font-optical-sizing (#4430)

From: Laurence Penney via GitHub <sysbot+gh@w3.org>
Date: Tue, 23 Jun 2020 18:20:36 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-648334672-1592936434-sysbot+gh@w3.org>
Thank you for those interesting results, @jfkthame.

I ran some tests using a special version of Selawik produced by @robmck-ms in October 2019 (he permitted me to share it). This allows us to record the exact `opsz` values used in rendering, rather than guessing visually. The results lead me to state that **current versions of Safari, Chrome and Firefox and not consistent in their handling of opsz**. Detailed explanation follows.

The font `Selawik-variable-opsz-no-avar.ttf` has two axes:

* `wght` is identical to the standard variable Selawik in Unicode.org’s [rendering tests repo](https://github.com/unicode-org/text-rendering-tests/tree/master/fonts)
* `opsz` is new, and has min=0, default=0, max=100 (there is no gvar data for this axis)

A remarkable feature of Selawik is that (by means of @Gr3gH’s special hinting instructions, brilliant use of components and OpenType subsitutions) its axis locations can be queried by setting special text strings in the font itself:

* `\axis0` obtains the normalized value in the range [-1,1] of the first axis, i.e. `wght`
* `\axis1` obtains the normalized value in the range [-1,1] of the second axis, i.e. `opsz`
* `\axis0hex` obtains the normalized value of axis 0 in hex
* `\axis1hex` obtains the normalized value of axis 1 in hex

I updated the [Codepen](https://codepen.io/lorp/pen/dyGWyPZ) mentioned above to be typeset in this version of Selawik, and used the `\axis1` string to report normalized `opsz` units, so we can now obtain the `opsz` axis location by multiplying by 100. I set the text size using CSS `font-size: 20pt`.

On macOS 10.14.6, MacBook Pro 15.4" Retina 2012, 100% zoom, resolution “Default for display”:
* Safari 12.1.2 reports 0.2000 (=**20.00** on the opsz axis)
* Chrome 83.0.4103.106 reports 0.2666 (=**26.66** on the opsz axis)
* Firefox 77.0.1 reports 0.2666 (=**26.66** on the opsz axis)
— and the same results on external Apple Cinema 24-inch (1920 x 1200) screen

On macOS 10.15.6, MacBook Pro 13" Retina 2019, 100% zoom, resolution “Default for display”:
* Safari 13.1.2 reports 0.2700 (=**27.00** on the opsz axis)
* Chrome 83.0.4103.116 reports 0.2666 (=**26.66** on the opsz axis)
* Firefox 77.0.1 reports 0.2666 (=**26.66** on the opsz axis)

So the reports above (notably [the note from @drott](https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-543179881)) that other browsers decided to match Safari behaviour, appear to be incorrect at least in both scenarios tested. In fact, it appears (_based on a very small sample_) that in macOS 14 Safari used CSS **pt** units as the reference to `opsz`, while Chrome and Firefox used px. Then in macOS 15, for 20pt Safari uses a 27/20 scale = 1.35 rather than 4/3 = 1.33333 used by the other browsers.

Behaviour using `px` units appears to be consistent on all three browsers on macOS 10.15.6, so Safari is curiously departing from the standard 4/3 pt:px relationship.

Please feel free to edit the font size and CSS font units in the Codepen CSS, and report `opsz` values for your system.

Note: According to the spec, `opsz` axis values, including the minimum, must be “[strictly greater than zero](https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_opsz)”. However, results were exactly comparable with a test font that used 5 and 105 for `opsz` min and max, rather than 0 and 100.

GitHub Notification of comment by Lorp
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-648334672 using your GitHub account
Received on Tuesday, 23 June 2020 18:20:37 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:12 UTC