- From: arrowtype via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 May 2020 22:47:22 +0000
- To: public-css-archive@w3.org
Whew, this is a long thread. I hope I don’t repeat points too much, but I think a couple are worth calling out. > There is no way for a font maker to make a single font that works the same in print as it does on the web. For example, many font makes have customers in the magazine, newspaper and book publishing world (as well as advertising), who care very much that print matches web. Echoing @robmck-ms on this – to me, this is the single biggest problem in the current implementation. As a personal example, I am working on a typeface which has a “Text” style at opsz=12. The basic idea here is to optimize this style for ideal readability at the common default text size of 16px on the web and 12pt in print (at least in MS Word). This is based on my speculation that the majority of the total words read in this font will be at platform default sizes. I do not want to disrupt text scaling between browsers and the rest of macOS, and I don’t think anyone here is suggesting doing that. I don’t really mind that 12pt on my MacBook screen is not the same at 12pt on a typographic ruler. However, I _do_ worry about how I will explain to people that even though optical sizing is “automatic” in web browsers, it automates in a way that makes things more confusing, so they will still have to use `font-variation-settings` to accurately match the design of Text between web and print. In my case, 12pt or 16px (on a MacBook Pro 16" screen at default scaling) is significantly physically smaller than 12pt printed out from a document in macOS Pages. The same [test site](https://codepen.io/thundernixon/full/ZEbVBrz) renders with still smaller physical size when viewed on an iPhone XR. This means that the optical size problem is compounded, because when the browser selecting opsz=16 rather than the intended opsz=12, it is inaccurate in the in an extra-unhelpful direction, making letterspacing even more extra-tight-fitting than its larger size. For designs that are high-contrast fonts (e.g. Didots), this would be an even worse problem. As @twardoch said: > When in doubt, it's better to user the lower opsz value. Choosing a “too low” opsz value will get you slightly clunkier text but it will be readable. Choosing a “too high” opsz value will get you unreadable text that’ll defeat the purpose of font-optical-sizing.  Before realizing the magnitude difference in physical scale between 12pt on screen vs 12pt on paper, I was pretty skeptical of the numeric scaling proposal at the top of this thread. However, with this physical difference in mind, I think it would be very sensible to give CSS users the ability to dial in the scaling of optical sizing. The one tweak I would suggest is that it would probably make more sense to newcomers for the default to be `font-optical-scaling: 1;`, and for this value to make 12pt in CSS apply opsz=12, to better meet the [OpenType spec](https://docs.microsoft.com/en-us/typography/opentype/spec/dvaraxistag_opsz) (“Scale interpretation: Values can be interpreted as text size, in points.”) and to help make sure that default text at 16px can use a default Text opsz. This would not have to change anything about the way browsers scale px or pt; it would simply modify the way opsz is called to be more accurate. And then, if a magazine publisher wanted to _really_ match a certain context (e.g. Safari on the latest iPhone) to their print design, they would have the ability to tweak this automated behavior to achieve that goal (or even use JavaScript to match many different devices to the print sizing & optical design). -- GitHub Notification of comment by arrowtype Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4430#issuecomment-631127192 using your GitHub account
Received on Tuesday, 19 May 2020 22:47:25 UTC