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

Adam Twardoch (Lists) list.adam at twardoch.com
Fri Aug 21 17:40:08 CEST 2020


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> 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>
>
> *On Behalf Of *Adam Twardoch
>
>
> *Sent:* Friday, August 21, 2020 7:58 AM
>
>
> *To:* MPEG OT Spec list (mpeg-otspec at lists.aau.at) <
> mpeg-otspec at lists.aau.at>; OpenType Font Variations list OTFontVar <
> 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%7Cd8b0db5c25994d72a1d808d845e2a429%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336187004385999&sdata=%2FyNtwwi6jcAr3wMnc4fN%2F6xFR9MQwBmYY3R5N2jslcg%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%7Cd8b0db5c25994d72a1d808d845e2a429%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637336187004395983&sdata=MM%2BrO2WPbV4HHi1m6RCtpLadLlQbltXFmYolJLBSBtQ%3D&reserved=0>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> mpeg-otspec mailing list
>
> mpeg-otspec at lists.aau.at
>
> https://lists.aau.at/mailman/listinfo/mpeg-otspec
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200821/cdd801bf/attachment-0001.html>


More information about the mpeg-otspec mailing list