- From: Laurence Penney via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Jun 2020 18:20:36 +0000
- To: public-css-archive@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