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

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

From: arrowtype via GitHub <sysbot+gh@w3.org>
Date: Thu, 21 May 2020 14:35:05 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-632121143-1590071704-sysbot+gh@w3.org>
What if the new axis were Optical Point Sizing, (e.g. `oppt` or `ptsz`)?

The main problems, as I see them, are:

1. Print-based applications set type in points, and this probably won’t change. Certainly, average word processors won’t add a choice of pt/px units, because average users would be perplexed by this. Further, professional designers are extremely unlikely to change their font sizes to px. So, simply changing `opsz` to px without a way to make this work in print would be bad for these users.
2. The web is obviously very centered on px units, and this probably won’t change, either. It is understandable that we wouldn’t want to change this & burden CSS writers with understanding that their font px sizing is converted to pts in the `opsz` axis. It’s still early, but treating `opsz` in px is already fairly established in browsers & macOS and may be hard to change (and not necessarily beneficial to change).

And yet, if there is no way to predictably design fonts that act in the same way, it will be confusing for everyone (as is the case now). Type designers will have to create different axes for print vs web, which would add additional complexity and chance for error, and additional burden on users to know what to select. This would also cause issues for platforms like Google Fonts & Adobe Fonts, as they too would be faced with the challenge of helping users navigate this complexity.

However, if there were axes for both `opsz` (in px) and `ptsz` (in pt), this all might be resolvable.

Browsers could request `opsz` at the px size as they currently do, but could implicity _also_ request `ptsz` at `px*0.75`. Print-based apps could request `ptsz` at the pt size, but could implicitly also request `opsz` at `pt*4/3`.

If a CSS user requests `font-variation-settings: 'opsz' 16;`, I believe this should also implicitly request `'ptsz' 12`, unless for some reason the user passes a different value for `ptsz`.

Then, in the OpenType spec, these two axes would refer to one another, making it clear to font designers that only one or the other of these axes should be used in the same font. It should also make it clear that software should make the implicit requests, with the suggested conversion of 3:4, pt:px.

Caveat: potentially, a type designer _would_ want different behavior between optical sizing in web vs print and so might reach for `opsz`+`ptsz` in the same font, _but_ I believe this would be a very good case for them to actually release two different fonts.

GitHub Notification of comment by arrowtype
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-632121143 using your GitHub account
Received on Thursday, 21 May 2020 14:35:06 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:07 UTC