[OTVar] Naming arbitrary instances

John Hudson

From http://typedrawers.com/discussion/comment/22862/#Comment_22862


Generating on-the-fly names for arbitrary instances within a variations space is difficult problem. What software needs in order to be able to unambiguously identify an instance is different from what users need if instances are exposed in font menus.

On the back end, there needs to be an identifier that can be used to instantiate on the system. That's what Adobe's new technical note on generating PostScript names for Font Variations does. This is important, because let's say you create a document using a custom, arbitrary instance, and then send that document to someone else who has the variable font installed: software needs to be able to accurately recreate the specific instance used in the document, which means the document has to store a pointer to that coordinate in the variations space, which depending on the document format might be no more than the generated PostScript font name. So there are good reasons why that name might need to be a concatenation of axis tags and axis coordinate values.

But such a name would totally suck as something to expose to users. On the other hand, generating human-friendly names for arbitrary locations in a multi-axis design space seems basically impossible. Let's say I have named instance (names for specific locations, stored in the font) for SemiBold and Bold: how can an algorithm automatically generate a unique human-friendly name for each of the possible locations in the design space between those two named instances?

This seems to me primarily a UI issue, and the solution probably has to involve allowing users to assign nicknames to instances. In CSS, this seems trivial, since basically anything in CSS can be given whatever name you like. In desktop apps, it is more complicated. An individual app or suite of apps might provide a model for assigning nicknames to instances, at the document level or in a shared library, but without any interoperability or consistency across the rest of the system or on other platforms.

I think there's room for a standard for nicknames for arbitrary instances, but am not sure where this would have to live, either in software or in terms of a 'home' for such a specification. Should it be part of the OT spec? If we want it to be as flexible as CSS naming, it isn't necessarily limited to variable font instances or even just to fonts.

Interesting subject.

James Puckett

There’s a horrible chicken and egg problem here: nobody really knows who is going to use these nicknames or how they’ll want to use them. Only a big UX research project is going to answer that question.

Georg Seifert

Apple had a UI for picking arbitrary instances. In the Typography panel had sliders that are visually on the same level as OpenType feature and such. I could imagine a system where you don't have a name but just specify coorinates. Like you specify the font size (that was referred to by name in previous times). Or like weight values in CSS. 

John Hudson

UI for selecting arbitrary instances is a different issue from identifying those instances. I'm not convinced that sliders are actually a good UI for variations, but in any case one would still need a way to reference instances. One wouldn't want to be fiddling with sliders each time one wanted to obtain the same instance in a document or accross documents. So I have in mind something in the mode of styles in InDesign — collections of text attributes that would include instance settings; nameable, updatable, and forkable — but ideally with some kind of standardised model that would be interoperable across software.

Nick Shinn

Graphic designers are familiar with CMYK as a means of specifying colors: four axes (channels) from 1–100 in each, and with the separate channels being visualizable, as additive functions.

It makes more sense to me than RGB.

Chris Lozos

A numbering system, an expanded version of Frutiger's original Univers system, would be great.  We would need to add a couple of digits though.

Thomas Phinney

tl;dr: The problem before was technical, not evidence of any boneheaded mistake by anyone making decisions about MM or axis-based fonts. It has been at least partly solved at a technical level, since.

* * * * * *

One of the problems was that style names used to have shorter length limits. So the use of horribly cryptic abbreviations in the style names like "WT256WD435OP22" was pretty much unavoidable. Nowadays one could do "the same" thing but use full names for things like weight and width, and put spaces in between "Weight 256 Width 435 Optical 22". I think even that would be a major improvement over the way this stuff worked back in the MM days.

Last I checked, Microsoft Office had shorter style name limits than OpenType required, which was highly unfortunate. Hope that has changed.

The new OpenType spec does define what the numbers actually mean, much more than in the aforementioned Olden Days of MM.

Ray Larabie

What if the interface were a bit like the color palettes in Illustrator? Users would have axis sliders and a palette of default style names. They could throw away styles they don't want, save new styles and rename them. Then save the palette. That way users could distribute the palette to everyone on the same project and use it as a style guide of sorts. Styles could be given names like "headline" or "small print" instead of "Optical Medium Semi-Condensed Semi-Bold Italic". Those same palette files could be used by CSS so the user would never have to see the cryptic axis settings.

Kayley Hill

Chris Lozos said:

A numbering system, an expanded version of Frutiger's original Univers system, would be great.  We would need to add a couple of digits though.

What a great idea, we could call them Frutigers and abbreviated as Ft (in the same manner as Pixels and Points).

Igor Freiberger

A panel like that would do the job, showing the predefined values (light, regular, etc.) but also letting the user insert values. The problem is how to handle the variable number of axis in this (or any) GUI.



Another possibility is to establish instances through OS and then let applications show just those instances as font variations. This may make easier to applications support the new technology and also promotes consistency as the user will see the same instances in any application. And if the user open a document with an instance not present, the OS just activate it and show an alert on screen.

Is this a bit oneiric?

Peter Constable

Thomas Phinney said:

[snip]
The new OpenType spec does define what the numbers actually mean, much more than in the aforementioned Olden Days of MM.

That's a somewhat stronger statement than I would have made. The scales for registered axes are defined in the 'fvar' table chapter, and some of the scales are actually given fairly specific semantics. It's true, though, that there is some degree of subjective interpretation.

For example, it says that weight scale uses values 1 to 1000 (fractions allowed) and that whole number values would be interpreted in the same way that OS/2.usWeightClass values are; but it doesn't give any objective definition to what (say) weight 550 means.

Or, as another example, it says that width scale values can be any value greater than 0, and that they are interpreted as percentages of whatever width the designer considers "Normal" for that family to be. But it say anything about how the designer should determine "Normal" or how precisely a comparison of widths should be made. (Average of "a-z"? Width of "i"? Width of some reference string?) 

Peter Constable

Igor Freiberger said:

A panel like that would do the job, showing the predefined values (light, regular, etc.) but also letting the user insert values...


Another possibility is to establish instances through OS and then let applications show just those instances as font variations. This may make easier to applications support the new technology and also promotes consistency as the user will see the same instances in any application. And if the user open a document with an instance not present, the OS just activate it and show an alert on screen...

The panel you showed is certainly made possible by the new 'STAT' (style attributes) table.

It would be feasible for custom instances to be defined with user-friendly names and then have those names presented in the app UI provided that the text formatting properties stored by the app is not that name but rather is the selected axis values.

Ray Larabie

Will the full axis names be stored in the font? How will localization of axis names be handled?

Peter Constable

Ray Larabie said:

Will the full axis names be stored in the font? How will localization of axis names be handled?

All names used in the 'fvar' and 'STAT' tables stored in the name table and use custom name IDs --- meaning (whether for good or bad) the same localization story as for any other strings. Both 'fvar' and 'STAT' will record axis names (via name ID references).

John Hudson

@Ray Larabie

To expand a bit on what Peter said: axis tags work very much like Stylistic Set or Character Variant OTL features. It is possible to define a name for a custom tag, and this name is stored in the upper reaches of the 'name' table, and the 'fvar' table contains a reference to the name ID location. The reason for doing it this way, rather than storing the name alongside the tag in the fvar table, is that the 'name' table is structured to allow localisation (translation) of any name ID string.

It isn't required to localise any name IDs, but one can. So if, for instance, you had a display type with an 'Bounciness' axis and Cyrillic and Arabic script support, you might localise this axis name as 'Упругость' and 'ارتداد'. Of course, that doesn't cover all the languages that use those scripts, nor guarantee that any other font with a bounciness axis will use the same translations, nor avoid potential cultural issues such as ارتداد meaning both bounciness and apostasy.  

Marcos Ojeda

As i think about this problem, i wonder about what it means to generate or access an instance. It feels a bit cavalier to call it a UI problem because it's really an issue in terms of how people understand what an instance is: whether or not it's virtual, defined by the font or defined by the application using it or defined by the user in the OS somewhere.

Say somebody hands me "Benton Sans OTVar" (thanks, btw, whoever you are!), I look at this shiny new font and wonder:

• do i need to have all 84 weights visible in every app?
• if so, our in-house style guide specifies only two allowable weights...
• if not, where is this set? per-application? (groan) systemwide? do i (or my vendor) need to remove or deactivate preset instances from the OTVar?

• is there any way to distinguish from styles that are user-made versus styles that are foundry supplied? 
• If so: why are they any different (if under the hood they are implement the same set of changes).
• if not: will this create the impression that custom styles defined are now embedded in the font. 
• when resolving a style name, will there be a hierarchy of possible locations to choose from: the font's vendor -> overridden by a stored os instance name -> overridden by the document's instances -> overridden by a (named?) inline style range?

• if i am responsible for maintaining my own "style sheet" of style names for each font, do i need each DTP App vendor to support the whole range of options? is there a standard for verifying compliance? (i.e. css' ACID. also, the past 20 years of consistent, reliable & rapid adoption and adherence to spec in multi-vendor style-sheet based applications)
• similar to color profiles: do i embed my instance hacks as an embedded Style Profile in the font and hope that my workflow is Style Profile-aware. Or will i (or ${DTP_APP} need to safely generate a new plain opentype instance when preflighting a document for my printer.
• If a font vendor defines custom style instances for a font, can those include other opentype features or only axial interpolation settings?

i guess my overarching point is this: giving instance names application-level precedence creates the impression that they are now "part" of the font. if, instead, those instance names are separate from the font, you have two places (or more) to look in order to find a conflicting instance name, but i don't think it's clear how collisions are handled.

when i use an opentype font with a few stylistic sets activated, i don't have any expectation that the font has actually changed (the settings are applied to some run of text of my choosing). The font name stays the same after all, the menus don't change, i just probably have a character/paragraph style entry now.

when i use an opentype variable font with custom instance names defined, am i to interpret all those settings to apply only to a range or paragraph? In this case, the font's name has changed, but what i'm actually seeing is a combination of multiple dip switches flipped and knobs dialed in and given some preset name. When i make changes and generate my own style names, they presumably appear in the same menu as the vendor's instances but i think that makes the nature of the instance even more befuddling than current opentype character styles.

in a sense, CSS has a somewhat easier go at this because you are implicitly expected to define @font-faces one-by-one (there is no ui that exposes real vs created instance names) but even css has the precedence/resolution problem to some degree: how does one handle name collisions? if there is a 'cascade', all places that show instances probably need to reflect the source of a given instance. Also, with the exception of user-styles (that few use) the cascade usually constrained to the context of the browser.

As it is, right now, macos/core text define a sort of loose algorithm for matching a string to a font/style/weight/size, but i suspect that this sort of font-resolution will be platform specific unless otherwise spec'd. I do think this is in many ways a much more daunting concept for end-users to deal with than Stylistic Sets and see no immediate indication that disambiguating instances won't be equally confusing "no, i see it just fine on my computer, it's in the font menu" "well... i don't?"

i looked through the spec this afternoon to see if it offered any thoughts about user-defined instances, but either i missed something or it's not considered. It seems that the data structure is only designed to accommodate the instance presets specified at build time but seems to imply that anything beyond that is either handled by the platform or specific applications, which seems unfortunate for font consumers who tend to, by and large, bear the burden of having to sort out these conflicting implementations.

that said, tell me if i'm barking up the wrong tree or have misunderstood this concept!

James Puckett

Marcos Ojeda said:

that said, tell me if i'm barking up the wrong tree or have misunderstood this concept!

I think you’ve got a good grasp on the problem. On the upside, Bohemian Coding and Serif (Affinity) are making huge strides in UX/UI for desktop design software. Maybe they’ll bring something great to the table.

I don’t think UX is a big deal in CSS. Even if the CSS implementation isn’t great only one person needs to figure it out. Then everybody else can just search Stack Overflow and copy/paste.

David Lemon

It's not in the spec as such, but Adobe's document on naming arbitrary instances addresses some of this. The names for arbitrary instances would be clearly different from named instances, because the arbitrary names need to carry information about the axis values used. Applications that allow users to create arbitrary instances will need to store the resulting information in the document where they're used, so someone else opening the document can see the same instance. And finally, when setting up for printing (and PDF embedding) the app or OS services will need to save a "legacy" version of the instance.

Thomas Phinney

Hi Marcos, You asked so many questions at once, it is a bit daunting. But since nobody else tackled them in full, here goes.... I will preface this by saying that it is possible that some OS or app will do things differently and surprise me. A lot of things are still developing and could change. My comments below represent my best guess based on past experience and my understanding of what everyone is up to, so far.

I do note that my understanding is that one thing not currently defined by the spec is a specific means for apps to interchange information about user-selected or user-defined instances. One could say that is a hole in the system.

Marcos Ojeda said:

As i think about this problem, i wonder about what it means to generate or access an instance. It feels a bit cavalier to call it a UI problem because it's really an issue in terms of how people understand what an instance is: whether or not it's virtual, defined by the font or defined by the application using it or defined by the user in the OS somewhere.

Default instances are those defined in the font. They are real and permanent and are going to show up in all apps. It is unlikely that an OS will offer a means to suppress default instances, although possible. More likely an especially savvy app might do this, but still not super likely, IMO. On-the-fly instances generated by user action are not particularly permanent, but could easily be baked into styles. It is possible that an app could create some other way of storing such instances. Currently there is no interchange mechanism for text formatted with on-the-fly instances outside of CSS.

Say somebody hands me "Benton Sans OTVar" (thanks, btw, whoever you are!), I look at this shiny new font and wonder: 

1. do i need to have all 84 weights visible in every app?
2. if so, our in-house style guide specifies only two allowable weights...
3. if not, where is this set? per-application? (groan) systemwide? do i (or my vendor) need to remove or deactivate preset instances from the OTVar?

1. See above. Short answer: it seems likely, yes.
2. OK, so just use those two weights
3. Unless an OS or app goes much further than I expect in this area, you won't be able to remove or deactivate preset instances.

Side note: I believe it is a Very Bad Idea to use the word “weight” where you actually mean “style.” It creates confusion and leaves you without an accurate word to use when you actually mean “weight” instead of “style.” (You are not alone in doing this, of course.)

1. is there any way to distinguish from styles that are user-made versus styles that are foundry supplied? 
2. If so: why are they any different (if under the hood they are implement the same set of changes).
3. if not: will this create the impression that custom styles defined are now embedded in the font. 
4. when resolving a style name, will there be a hierarchy of possible locations to choose from: the font's vendor -> overridden by a stored os instance name -> overridden by the document's instances -> overridden by a (named?) inline style range?

1. The foundry-supplied styles (default instances) have names, and probably (up to the foundry though) those names do not include the coordinates. Unless an app or OS does something unusual, the user-made styles will not have names, and will be displayed with design space coordinates.
2. The format allows default instances to be named because that's helpful and people like named styles. But because user instances are completely open-ended and near-infinite, and users may not want to be interrupted by naming, it would be unreasonable to require user instances to be manually named.
3. No
4. This has been answered above. But really there are only issues if you assume multiple sources of named instances and assume that instances are being solely called by name. My expectation is only one source of named instances (the font), and everything else working on coordinates.

1. if i am responsible for maintaining my own "style sheet" of style names for each font, do i need each DTP App vendor to support the whole range of options? is there a standard for verifying compliance? (i.e. css' ACID. also, the past 20 years of consistent, reliable & rapid adoption and adherence to spec in multi-vendor style-sheet based applications)
2. similar to color profiles: do i embed my instance hacks as an embedded Style Profile in the font and hope that my workflow is Style Profile-aware. Or will i (or ${DTP_APP} need to safely generate a new plain opentype instance when preflighting a document for my printer.
3. If a font vendor defines custom style instances for a font, can those include other opentype features or only axial interpolation settings?

1&2. You are basing all this on the presupposition that user-generated names for arbitrary instances are desirable. (But even aside from that, we need a reliable way of interchanging just font coordinate settings along with the font name, for formatted text across apps.)

3. The font vendor MUST define at least one style instance for the font, at least with TrueType outlines. I think the PS outline case is the same in that regard. So it is not an “if.” This instance does not include OpenType settings except/unless those are inherent in the design space coordinates.

That is, for example, the font’s designer can set up the font to automatically swap to a different version of a glyph for a specific part of the design space. The example shown in demos is to have a dollar sign where the vertical bar(s) stop going through the middle when there isn't enough space, at bolder weights. That's fine. But if so, that will happen any time somebody goes into a specified point or range of the design space to get an instance.

One could restrict it to just the exact coordinates that happen to coincide with the named instance, mind you. What the font creator can't do as far as I know is just decide to set up a named instance and for the heck of it turn on oldstyle figures for just that named instance, yet somebody just exploring the design space and hitting the same coordinates would *not* automatically get the oldstyle figures.

Of course, this is not an issue peculiar to variable fonts—it is equally true of OpenType features outside of variable fonts. With either variable or flat OpenType fonts, in a sophisticated text-handling app, you could use a character or paragraph style to combine a specific font selection with whatever other OpenType formatting you wanted.

i guess my overarching point is this: giving instance names application-level precedence creates the impression that they are now "part" of the font. if, instead, those instance names are separate from the font, you have two places (or more) to look in order to find a conflicting instance name, but i don't think it's clear how collisions are handled.

when i use an opentype font with a few stylistic sets activated, i don't have any expectation that the font has actually changed (the settings are applied to some run of text of my choosing). The font name stays the same after all, the menus don't change, i just probably have a character/paragraph style entry now.

when i use an opentype variable font with custom instance names defined...

Again, you assume that there is a mechanism provided or available to name your custom instances. We haven't seen that in the past with MM or GX Variations, and I think you are providing good arguments why it might be a Bad Idea to have one now.

Of course, one could modify the font file and bake the custom instances into the font. That would have the usual issues associated with no-modification clauses in the font license, and making sure the modified font goes where you need it to go. Those are the same issues that have faced people doing custom kerning and other mods for decades.