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

John: "Once you have a flexi-unit, you really can't make any assumptions or
predictions."

Yes, you can't. You have a flexi-unitized distance of user, and size of the
font, and weight, contrast and width.

And as Type Size in the world at large is a standard based on other
standards, and lots of other sized things have other units systems also
based on those standards.
So, we are here conversing about CSS not having the ability to represent
any of those standards or their offshoots, or know how much they are scaled.


On Wed, May 27, 2020 at 5:57 PM John Hudson <notifications@github.com>
wrote:

> Perhaps I should say 'quantization' rather than 'rasterization' as the
> point is that the glyph outline design (what I just called the '1000 UPM
> grid') is resolved to a 'css px' grid, that has a varying "resolution", and
> that grid, not a physical size, is what MUST be targeted - because the
> actual physical size has been abstracted away, along with ppem raster sizes
> and real pixels.
>
> And yet it isn't really abstracted away, because there is an actual
> physical size to a piece of text that is displayed to a reader. There may
> be difficulties in determining what that size is going to be from an
> upstream perspective, given the variety of devices, platforms, libraries
> involved, and there may even be difficulties in determining what that size
> *is*, given the variety of resolutions involved. But the text is an
> actual, physical size, which is what the optics of the reader is seeing,
> and which optical size is supposed to address. If it really can't address
> that physical size any more, maybe the thing to do — given all those givens
> — is to throw out the concept of optical size as it is currently understood
> by type designers and typographers, to throw out all the analogues to
> size-specific metal fonts, and to instead embrace a more vague, less
> size-specific concept of 'size tuning' of design: smallest, smaller, small,
> smallish.... That suggests the possibility of a properly abstracted ‘size’
> axis scale like that we have for wght, in which CSS might define what big
> round number equals 'Smallest' then 'Smaller' etc.. Then we could stop
> worrying about points and pixels, and just avar map our design spaces to
> the abstract scale.
>
> The opsz scale HAS ALREADY been redefined to use 'px' as a unit.
>
> What we disagree about, I think, is the implication of that decision. It
> isn't just a change to a different unit, but from an absolute, physical
> unit to an uncertain flexi-unit. Redefining the opsz scale to use px as a
> unit means redefining it as not optical. Yes, we can say that Mac OS is the
> oddity in the way it makes a kind of px and a kind of pt equivalent, and
> hence the size of px on that platform vs other platforms, but I'm not left
> with any reassurance that it is the only oddity or will remain the only
> oddity. Once you have a flexi-unit, you really can't make any assumptions
> or predictions.
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-634964196>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAO5VDXE6I4DYZ5PEAB3AVDRTWEDRANCNFSM4JBXYCMQ>
> .
>


-- 
GitHub Notification of comment by dberlow
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-635237633 using your GitHub account

Received on Thursday, 28 May 2020 09:46:38 UTC