[MPEG-OTSPEC] STAT instances, fvar instances and auto optical sizing

Fri Aug 21 17:54:42 CEST 2020

Two purposes originally:

  1.  It provides options to UI designers. E.g., it can facilitate something like what I described in (b).
  2.  It provides a means of backward compatibility for existing applications or libraries that were designed assuming more limited font family models. For example, existing Xamarin APIs assumes that a font family is limited to only wght, wdth or ital/slnt axes, and a variable font with opsz or any other axes wouldn’t work well unless there’s some way that it could project the n-axis named instances of the variable font into Xamarin’s WWS assumptions.

I believe (i) was the primary purpose the idea was originally developed within Adobe (though they didn’t call it STAT). But (ii) was the main reason it was made required for variable fonts.

Peter

From: Adam Twardoch (Lists) <list.adam at twardoch.com>
Sent: Friday, August 21, 2020 8:40 AM
To: Peter Constable <pgcon6 at msn.com>
Cc: MPEG OT Spec list (mpeg-otspec at lists.aau.at) <mpeg-otspec at lists.aau.at>
Subject: Re: [MPEG-OTSPEC] STAT instances, fvar instances and auto optical sizing

Hmm... So what's the purpose of STAT (and why is it required in VFs)? I never really knew.

For some time I ignored STAT, only later I realized that it actually is almost exactly the same as the "axis instances" that I designed for FontLab VI before I heard of STAT.

My thinking was that the particle names are there so that in a multiaxis font, a UI can opt in for a multi-dropdown UI with ~10 or less entries in each. — But this may be because I was biased, since that's the thinking I originally had for managing instances in FontLab :)

If you use the STAT particle names purely to synth a full style name, then you end up with another huge list that duplicates the fvar list, no?

The problem with the single-list approach is of course that it quickly becomes a UX nightmare in VF. 9 weights, 5 widths, 5 optical sizes & 2 italicizations in STAT, combine them and you have 450 entries. Then the "style list" needs its own search engine :D

I thought STAT was there to help in that. Apps could adapt their style selection widgets so that in a font that has no STAT, the app shows a plain list, but with STAT, it switches to multi-list/multi-column.

But — I've jumped ahead with my thinking. I'd love to hear the use cases actually envisioned by those who created STAT!

(And I don't mean the back-formation of friendlier names from location regions, like Photoshop does it. I get that :) ).

A.

On Fri, 21 Aug 2020 at 17:17, Peter Constable <pgcon6 at msn.com<mailto:pgcon6 at msn.com>> wrote:

Great question, Adam

I think there are alternate possibilities; here are two off the top of my head:

a) Based on the current font size, the picker UI highlights (in some way) those instances that match the size with the opsz axis. The user could still choose an instance that contravenes the opsz if they want, but they see which are “recommended”

(given some assumptions about the eventual display environment).

b) There is an auto-opsz option somewhere. If disabled, then something like (a) can be offered as UX. But if enabled, then in the font picker UI the instances are folded so that there are only wght options offered. The subfamily strings

displayed would either omit the opsz-distinguishing labels (e.g., “Light” but no “Display Light”), or perhaps the strings could show the opsz labels that are encompassed, e.g., “Light (Small/Text/Dislay)”.

I’m sure there are other possibilities.

Btw, one thing to point out: while independent controls for each axis might be workable for variable fonts, it can become really problematic for a family of static-instance fonts. (Back in 2008 or so, I started to design font controls for

Windows 7 using this approach, but then realized it has bad UX issues.)

Suppose within a family there are 3 wght values represented, and 3 opsz values represented: if the family is fully populated with all 9 combinations, then the UI works. But if the matrix of possibilities is sparsely filled, then the UX

becomes pretty bad: either the choices shown in one control change by the state of the other control, or else each control shows all options but a choice in one control can invisibly change the setting of the other control.

For that ready, I would strongly caution against a UI design such as what you described in (3) in your message.

Peter

From: mpeg-otspec <mpeg-otspec-bounces at lists.aau.at<mailto:mpeg-otspec-bounces at lists.aau.at>>

On Behalf Of Adam Twardoch

Sent: Friday, August 21, 2020 7:58 AM

To: MPEG OT Spec list (mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>) <mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>>; OpenType Font Variations list OTFontVar <otfontvar at unicode.org<mailto:otfontvar at unicode.org>>

Subject: [MPEG-OTSPEC] STAT instances, fvar instances and auto optical sizing

1. Let's say a font has the wght axis with the STAT instances "Light", "(Regular)" (elided) and "Bold". It again has the opsz axis with the STAT instances "Small", "(Text)" and "Display".

The fvar instances permute those, so:

- Shall Light

- Light

- Display Light

- Small

- Regular (from elided fallback)

- Display

- Small Bold

- Bold

- Display Bold

2. Let’s say a desktop app implements behavior like CSS "font-optical-sizing: auto", i.e. the app automatically chooses an "opsz" value based on the font size (let’s disregard

the question of specific units).

3. Let's say the app implements a STAT-based style selection UI, with one drop-down per STAT axis. In this model, it seems that the opsz drop-down, should list Small, Text,

Display AND should have an extra entry "Auto" which makes it work like "font-optical-sizing: auto". Do you agree? I think that's reasonable enough. Then, if any of the other opsz entries are chosen, opsz would be frozen at the associated STAT value.

4. But what should be done in a model that lists fvar instances as styles? Every fvar instance IS tied to some opsz value. So would the recommended UX be that there is some

kind of "checkbox" somewhere that basically says "Font size chooses optical size" or something, and THEN choosing the "Small" style vs. the "Display" style would have no visual effect?

--

Adam Twardoch

http://www.twardoch.com/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twardoch.com%2F&data=02%7C01%7C%7Cc61e2c5332724b2576a808d845e884cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336212240841640&sdata=YPsROqtnqGdO9vltitC7ZSTSl0wMEp1VBPwi8S3%2Bm%2BE%3D&reserved=0>

--

Adam Twardoch

http://www.twardoch.com/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.twardoch.com%2F&data=02%7C01%7C%7Cc61e2c5332724b2576a808d845e884cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336212240841640&sdata=YPsROqtnqGdO9vltitC7ZSTSl0wMEp1VBPwi8S3%2Bm%2BE%3D&reserved=0>

_______________________________________________

mpeg-otspec mailing list

mpeg-otspec at lists.aau.at<mailto:mpeg-otspec at lists.aau.at>

https://lists.aau.at/mailman/listinfo/mpeg-otspec<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.aau.at%2Fmailman%2Flistinfo%2Fmpeg-otspec&data=02%7C01%7C%7Cc61e2c5332724b2576a808d845e884cc%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336212240851625&sdata=ia03DsnJY8bCeLhYO9v3saUoZ%2Bgr1c%2Fgvvge55yS94E%3D&reserved=0>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200821/e89ad31d/attachment-0001.html>