Recalibrate opsz from 1/72in to 1/96in
davelab6 opened this issue · comments
I'd like to propose 'recalibratinig' the opsz axis.
Summary/Conclusion
The way opsz values are interpreted has become ambiguous, by 1⅓. 72 or 96 is a big difference. It is important for everyone to come into consensus on what opsz units mean as soon as possible, and the next round of GF VF fonts can demonstrate leadership here.
Details
1. ‘CSS pt’ is not ‘physical pt’ – and ‘CSS px’ has no consistent physical size
The OT spec says opsz values are meant to be physical Points, but "css pt" is not actually physical pt, it is "4/3 * px" - and px is not defined as a physical unit. This by itself is not too big of an issue, but is not ideal :)
2. Zero browsers follow the OT spec for opsz == pt, all use px instead
They all have decided to use px instead of pt, thus "mis-implementing" auto-opsz. This is a big deal.
Eg, Google Sans Text is currently coded to start interpolating at 18 pt and be fully used at 14 pt, but currently GST will start at 24 pt and be fully used at 18.6 pt – a big difference!
3. CSS says pt == 4/3 px, but Apple says pt == px
How did (2) happen? Because all Apple systems have always broken the CSS spec and treated pt == px, and because Apple was the first to implement auto opsz, all others ended up matching them by using px instead of pt.
- A solution (1) and (3) is CSS authors scaling opsz values
The proposal to W3C CSS WG (github.com/w3c/csswg-drafts/issues/4430) by Laurence Penney and Adam Twardoch is (and insanely long discussion and is) for CSS authors to adjust the way opsz unit are interpreted by some factor, so that if you want to scale opsz for apple systems to match all others, you can – and also if you want to deal with (1) – by end-users calibrating their devices so you can scale css pt to == physical pt, you can.
5. A solution to (2) is to update the OT spec
John Hudson was co-author of Microsoft's opsz definition, and his proposal is to update the OT spec opsz definition from physical pt of 1/72nd of an actual inch to 1/96th, which is as close as we can get to 'css px' values (and for mobile apps, dp in Android, and pt and px in macOS/iOS).
Since no design/desktop app has shipped auto-opsz yet, I think we are still within a window of opportunity to make this change without major disruption; such non-px based apps can get a pt value by a simple 4/3x multiplication.
6. Anticipating this, all Google Fonts fonts with opsz axes need to calibrate the axis on 1/96in not 1/72in
Here we are :)
So, I'm asking you to change the values of the masters appropriately, and rename pt to px in STAT/fvar named style strings.
Since this comment has fallen here, and I'm not the most mathematical person on the planet (in fact, a counting-on-his-fingers-and-toes kind of guy), I want to make very sure I understand what's being requested. Currently my opsz scale runs 6-18, but each of those numbers needs to be multiplied by 1⅓, so the scale will now run 9-24, with appropriate adjustments for each instance + renaming "pt" to "px." So, for example, "10pt SemiBold" will now be named "13px SemiBold" and the Optical Size number should be 13.333 (or should I round?).
Do I have it right?
Sorry, it seems I was premature in opening this, as this is still being discussed at w3c and the OpenType Specification cabal, so I will close this issue now, but might reopen it later.