[MPEG-OTSPEC] STAT instances, fvar instances and auto optical sizing
Peter Constable
pgcon6 at msn.com
Fri Aug 21 17:17:29 CEST 2020
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200821/14594e7c/attachment-0001.html>
More information about the mpeg-otspec
mailing list