- From: John Hudson via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 May 2020 17:31:41 +0000
- To: public-css-archive@w3.org
> Browsers could request opsz at the px size as they currently do, but could implicitly 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 scaling is implicit, why do we need two axes? My main concern about the proposal to redefine the scale unit of the opsz axis to px — apart from grumpiness about rewarding people for ignoring the spec — is that as type designers we have accumulated knowledge and experience about designing for and with the two sets of units — font units per em and typographic points — that are the common currency of our work. I know and can form mental pictures of 6pt type and how it differs from 12pt type, and my font development tools and most of my proofing environments are all built around the same units. I don't have a mental image of 6px or 12px type. So I'm trying to imagine how, as a type designer, I would approach designing for an opsz axis in px units, and what kinds of tools I would want to that task that differ from my current tools. Probably, I want to continue to design point size masters, and have a px axis scale calculated on export. Then there's the page layout apps, word processors, etc. that will have the job of interpreting (scaling) the px opsz axis to points and other units used internally. And what is the likelihood that some big player will decide 'Oh, we're just going to interpret the scale as typographic points, because that's easier for us and fits with some knot that we've previously tied ourselves up in'? -- GitHub Notification of comment by tiroj Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-632241500 using your GitHub account
Received on Thursday, 21 May 2020 17:31:43 UTC