[csswg-drafts] [css-fonts-4][varfont] Automatic optical size/style selection

robmck-ms has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-fonts-4][varfont] Automatic optical size/style selection ==
Back when we added Sitka to Windows 8.1, we spent a lot of time 
looking into automatically switching optical styles. @litherum asked 
me to summarize our findings here.

This discussion applies both to variable fonts with an optical size 
axis, as well as static families that have optical styles (like 
Microsoft Sitka, Adobe Kepler and Garamond Premiere Pro, etc).

There are a number of reasons to make text bigger or smaller. Here's 
just a few:
- To express semantic relationships and information hierarchy 
(headlines vs text vs caption)
- To make the text more readable for a given user's visual acuity.
- To zoom in and look at detail, or to zoom out to get an overview 
(e.g. pinch-zoom).
- To project to a roomful of people.
- ...

Optical fonts are designed so that they optimize for legibility at 
small sizes, and optimize for personality at large sizes. The 
selection criteria is your ability to read at a given size, which 
ultimately comes down to the acuity of the human eye.  In an ideal 
world (complete with frictionless pulleys), you'd select the optical 
style of a font based strictly on the visual angle that the text 
subtends as light enters your eye. This visual angle relates directly 
to the resolving power of your retina, lens, and any eyewear you 
happen to be wearing. Smaller angles push the limits of your optics, 
so you need extra legibility in letterforms to compensate for your 
eye's shortcomings.

Unfortunately, visual angle as an input variable to optical style 
selection breaks down when we try to apply it in the real, digital 
world. People have a wide range of visual acuity, even corrected, thus
 the visual angle you might want to use to transition to a caption 
style for one person may be very different for another. In a 
projection scenario, visual angle varies too widely to be useful. 
Someone in the front of the room looking at a bit of text can have 
4-5x greater visual angle vs someone in the back.  Also, sometimes, 
you just want to zoom in to look at detail, thus the visual angle 
increases, but it's not relevant to the user's task.

One could also look at using physical, rendered size on screen, but 
that too has many problems. In accessibility scenarios, you end up 
with a floor function in the design of the font, with all text 
displaying at the optically smallest style, eliminating information 
about hierarchy and semantic relationship. In projection scenarios, 
you'd have the reverse - everything displayed in the optically largest
 style, which not only loses hierarchy, but is inappropriate: folks in
 the back of the room would have a hard time reading smaller text. 
Another issue is the scaling factors that operating systems use in an 
attempt to simplify layout on displays of vastly different pixel 
density and sizes (you end up having to reverse out the scaling 
factor, choose the style, then use the document specified size, and 
hope it all comes out ok in the end). 

In the end, the approach we found worked best was that optical style 
was a function of the text size _within the document_. E.g. If the 
user selected 10pt type in Word or in CSS, then that is used to select
 the optical size, regardless of how big the letters end up in the 
real world. I.e. Pinch-zoom and other zoom actions (accessibility, 
ctrl-+, etc) happen _after_ style selection.

This approach preserves information hierarchy and relationships in all
 scenarios. Zoom controls for accessibility let users adjust the 
overall size to one that is appropriate to their visual acuity 
(essentially, recalibrating the visual angles for optical selection). 
Zoom also works more intuitively (i.e. it's making the layout you're 
looking at bigger and not "changing" the document - especially 
important in document apps like Word or PowerPoint where people are 
very invested in preserving a particular layout). It does leave 
projection scenarios to fall where they may, but that is true of type 
size and layout on projectors anyway (which are treated like really 
big desktop monitors). 

So, for HTML/CSS, I'd propose the value of the font-size parameter, 
converted to points, would be used for optical style selection. For 
variable fonts, this would be the user coordinate of the optical size 
(opsz) axis). For static font families, this would be used to select a
 font based on the STAT table (see #806). 

We don't yet have any products that ship support for optical style 
switching; we needed to build the infrastructure in the font format 
first.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/807 using your GitHub 
account

Received on Thursday, 15 December 2016 00:22:28 UTC