From
http://typedrawers.com/discussion/comment/22862/#Comment_22862Generating 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.
Comments
It makes more sense to me than RGB.
* * * * * *
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.
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?
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?)
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.
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).
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.
Say somebody hands me "Benton Sans OTVar" (thanks, btw, whoever you are!), I look at this shiny new font and wonder:
- 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!
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.
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.
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.
- See above. Short answer: it seems likely, yes.
- OK, so just use those two weights
- 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.)-
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.
- 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.
- No
- 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&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.
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.