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

> Why not just have browsers on each OS honor their OS's design? 

That's an important question. Paraphrased: why break consistency with other apps on the OS (especially after so much work went into getting the text size the same)?

Ultimately if you maintain that consistency, and the web follows the macos convention, then legibility will be reduced (due to using higher opsz than designed), and it will not be possible to build one font that works on both web and print. 

But, I think you already have a consistency problem anyway: Safari will set opsz=16 for 12pt. Will TextEdit or Pages use opsz=16? I would expect that they would just call CoreText with 12pt, and since CoreText thinks 1pt = 1pixel (and has no 4:3 bulit into it), won't it use opsz=12? If so, native apps on macos will use opsz=pt, because there's no 4:3 mapping, while Safari uses opsz=4/3pt. That means the optical style will differ between Safari and these apps, despite them being rendered at the same physical size.

Looking beyond that, any app that considers print a primary endpoint (e.g. Microsoft Office, Adobe InDesign, Pages?...) will likely use the document point size for automatic optical size. I.e. 12pt text will use 12 opsz. (If/when Office supports automatic optical size, this is what we will do). When it comes to print, there's realy no other option: there is no other unit analogous to CSS px to fall back on (there is no device-independent pixel in print), and the output is always consistent (12pt is exactly 12/72"). So, between these apps and Safari, all set to 100% zoom, you'll have consistency in physical size, but inconsistency in optical style.

(It's worth noting that when I talk about print, I'm not just talking about printing a Word doc on your laser printer; I'm including the whole print industry - books, magazines, newspapers, advertising, packaging, etc. They're all run on applications that run on Windows and MacOS (more often on the latter)).

Ultimately, then, it looks like there's a tradeoff: On one hand: internal consistency on a given platform; on the other: legibility and the ability to make one font that works the same in print and web. If internal consistency is possible (I don't know that it is), is improving legibility and enabling one font to server print and web worth breaking that consistency? Or flipped: Is maintaining internal consistency worth reducing legibility and requiring print & web fonts to be built differently? 


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

Received on Friday, 1 November 2019 19:04:44 UTC