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: John Hudson via GitHub <sysbot+gh@w3.org>
Date: Mon, 22 Jun 2020 23:05:23 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-647812122-1592867122-sysbot+gh@w3.org>
> The most "correct" answer, AFAICS, should be that auto opsz = CSS font-size in pt, but it seems browsers are currently shipping with opsz = font-size in px. I think this is a mistake, and we should fix it; the compatibility impact of doing so will be minor, as per #4430 (comment).

On this we are in complete agreement.

With regard to how opsz design variation targeting physical size should be interpreted and implemented in the naturally uncertain world of relative units, when the actual size of text seen by the reader and the physical distance from the reader cannot be known, my take is perhaps only subtly different from yours. I think the opsz axis as defined in the OpenType axis definitions registry, needs to give font makers guidance on how to design for opsz and other software makers some concepts on how to understand the aims of size-specific design. It is up to downstream standardisation and implementation to determine the appropriate way to implement opsz given the scale unit of the the axis definition and the information available, more or less incomplete, regarding size of text seen by the reader. So I'm not in favour either of the opsz axis definition trying to tell software makers they have to do something that is effectively impossible, nor in having it fail to suggest what they might do in a best case situation because we assume what is unknowable in some situations now will be unknowable everywhere and always. :)

So if the approach that some software makers take now is that opsz 1/72 inch point (standard use of point throughout the OpenType specification) is interpreted as equivalent to CSS pt, that seems to me one reasonable approach for some environments. My understanding is that it wouldn't be a reasonable approach for Apple given their existing scaling model and equivalences across their platform, so it actually doesn't make sense for this intepretation to be defined at e.g. the CSS level or elsewhere in web standards.

GitHub Notification of comment by tiroj
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-647812122 using your GitHub account
Received on Monday, 22 June 2020 23:05:24 UTC

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