Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-fonts-4][varfont] Automatic optical size/style selection #807

Closed
robmck-ms opened this issue Dec 15, 2016 · 12 comments
Closed

[css-fonts-4][varfont] Automatic optical size/style selection #807

robmck-ms opened this issue Dec 15, 2016 · 12 comments
Labels
css-fonts-4 Current Work

Comments

@robmck-ms
Copy link

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.

@davelab6
Copy link
Contributor

I'd propose the value of the font-size parameter, converted to points, would be used for optical style selection

I'm not sure about a font-size value in pt, because 'base' PPI varies, on Microsoft and Web platforms it is 96, while on Apple it is 72.

cc @dberlow

@dberlow
Copy link

dberlow commented Feb 24, 2017 via email

@litherum litherum added the css-fonts-4 Current Work label Feb 27, 2017
@litherum
Copy link
Contributor

litherum commented Mar 7, 2017

This is incredibly helpful. Thank you so much, @robmck-ms.

@litherum
Copy link
Contributor

litherum commented Mar 8, 2017

Because font-optical-size doesn't actually let web authors set the optical size value directly, I'd imagine this description is most valuable to implementors to figure out what to do when font-optical-size is auto.

I think the best way forward is to summarize this advice and put it into a non-normative section in the fonts spec. @robmck-ms: Is it okay if I put the following text into the spec? (Also please feel free to revise / comment on it)

This section is non-normative.

Selecting a value to supply for the 'opsz' variation axis when the 'font-optical-size' property computes to 'auto' is explicitly not defined here. However, there are some best practices found experimentally for selecting this value.

In an ideal world, the optical size value would select the optical style of a font based strictly on the visual angle that the text subtends as light enters your eye. 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. 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.

In the end, one approach that could work well would be that optical style is a function of the text size within the document. For example, if the content specifies 10pt type, then that is used to select the optical size, regardless of how big the letters end up in the real world.

@behdad
Copy link

behdad commented Mar 8, 2017

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).

This is also my recommendation.

@litherum
Copy link
Contributor

litherum commented Mar 8, 2017

Given that everyone seems to agree to using font-size, perhaps we should make that part normative. We could say something like "font-size must be taken into consideration when selection a variation value for the 'opsz' axis, but other signals may also be considered." Then, we could test it by making sure that different values of font-size yield different visual results.

@robmck-ms
Copy link
Author

Yes, feel free to use this. I agree that we should make the mapping from font-size to opsz more explicit. I worry about "but other signals may also be considered" because type designers won't know those other signals, thus won't know how to design accordingly.

I think it's important to say that this size selection happens before browser zoom or OS scaling.

@litherum
Copy link
Contributor

I think it's important to say that this size selection happens before browser zoom or OS scaling.

It already does, to some extent. It states that only zooms which affect layout may change the selected value for this variation axis. However, I can't define what layout-affecting zoom is because every browser has their own concept of zoom and many of them are subtly different. (And, by that same logic, I also don't want to specify what exactly "layout" is either.)

I don't want to specify the exact algorithm for selecting the variation axis value because this should be a place where browsers are allowed to innovate. But I also do want to help implementers not choose a terrible algorithm. That's the reason for the "This is a good place to start, but feel free to expand beyond it" wording. Perhaps we could put an explanation in non-normative text describing that this value is expected to be "close" to font size. What do you think?

@dberlow
Copy link

dberlow commented Mar 10, 2017 via email

@litherum
Copy link
Contributor

Yep. Safari has at least 4 kinds of zoom.

@robmck-ms
Copy link
Author

@dberlow has a good point about selecting opsz after browser zoom. I looked into this. My understanding, though, is that browser zoom is more often used by people with low vision to make text readable than it is for other uses.

For these users, who need to use very large text sizes, selecting opsz after zooming would shift all the text towards display styles, which is exactly the wrong thing for them. For low vision users, it's more helpful to have all the design choices embodied by small and text optical styles as those prioritize legibility. So, selecting opsz before browser zoom is more helpful. This is the motivation behind my accessibility point above. It does mean that typography suffers for those with normal vision, but it also helps people with low vision read better.

We can put this point in the non-normative portion of the spec. I suspect then, those with vision problems will gravitate to those browsers that implement selection before zoom.

@litherum
Copy link
Contributor

I think I've addressed the things this conversation has brought up, so I'll close this bug. Please reopen or let me know if you think the above commit isn't appropriate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-fonts-4 Current Work
Projects
None yet
Development

No branches or pull requests

5 participants