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

> That would be addressed with avar2.

Thanks, that was my conclusion. (avar2 is the new name for xvar, correct?) Any guess at when this might this be implemented?

To @davelab6's comment:

> So, average word processors don't need to add a choice of pt/px units, and average users don't have to do anything – and if the OT spec is NOT updated, then the average users WILL be perplexed by hugely inconsistent font styles.
> 
> Similarly, professional designers don't change their font sizes to px and remain in pt.

I am concerned that professional designers (or designers using pro tools, e.g. InDesign, Illustrator, Sketch, etc) will still want to have confidence that they are using the correct optical sizing. If they enter font size "10" and they allow `opsz` to be automatically set, won’t they be confused that their variable axis UI shows `opsz` at "13.333"? Presumably, this would lead to errors – I trust CSS devs to generally have a better grasp that font sizing can inherently have multiple different values, as this is core to the use of CSS (e.g. CSS authors use em, rem, vw, %, depending on their goals, whereas a print designer would very seldom stray from font sizing in points). 

Maybe a good argument in favor of opsz in px is that print apps tend to base font selection on named instances, so users wouldn’t normally be confronted with the conversion. Most print designers still haven’t encountered the opsz axis yet, so they probably would just accept that its scale wasn’t set to match pts, even if they never quite understood the conversion. And, those that really wanted to understand conversion could figure it out.

---

To @litherum's comment:

> > Thus, if you open a number of apps - Word, Pages, Text Edit, and Safari, with documents that specify 12pt in the documents coordinate system, and render at 100% zoom, Safari will render with opsz=16 and all others will use opsz=12.
> 
> I thought I showed in #4430 (comment) that 1 CSS px in all browsers on macOS = 1 point in all native apps on macOS (for some definition of “all”). It seems to me that opsz values fall out naturally from this.

When text is at 12px in Safari, that indeed matches the font sizing of 12pt in macOS Pages at 100% scaling. Because Pages does not yet allow for custom variable axis settings and does not select opsz automatically based on size  (it currently just allows selection of instances within a VF), I can’t say what opsz it might use for 12pt text, were it to support opsz in a more automatic way in the future. 

However, if the OpenType spec remains the same, I would hope that Pages would set opsz=12 for 12pt text, so that printed documents would use the accurate opsz setting. If the opsz value were changed between what was shown on screen and what was printed to paper, then it might allow reflow to happen, which would be a pretty bad outcome. 

And so, it would be better for Pages to preview opsz in points, regardless of the physical size on screen.

---

To @Lorp’s comment and others about not being able to predict real size:

> I have no idea how to keep it at its native “Actual size”. How opsz is supposed to cope with this, I have no idea

I think this is the best case for the original proposal here, adding scaling numbers. Site owners who are really trying to get close to correct physical optical sizing could probably do so with some JS + CSS. 

But, as you say, there is no clear documentation around what devices have what physical scaling, so this would basically require someone to do a lot of testing, and may need something like an NPM package to handle decently.

In the end, it’s hard to even be confident in knowing what paths there are forward on this. I think the options I see are:

1. Browsers change opsz to use pt values, disrupting existing implementations and requiring CSS devs to understand conversion if they want predictable results.
2. The OpenType spec changes opsz to use px values, requiring print designers to understand the scale conversion if they want predictable results. 
3. OpenType makes the oppx & oppt axes, and apps query for both with the conversions done implicitly. The main drawback here is that probably not all apps would adopt this, and users & type designers might be confused at the related but mutually-exclusive axes.

Maybe "the web way" just wins this one and we end up with route 2, simply because the web was the faster platform to adopt & support this axis?

In any case, I still think the original proposal here would be a helpful way devs could patch the fact that physical size varies by device. 

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

Received on Thursday, 21 May 2020 21:32:11 UTC