[MPEG-OTSPEC] STAT Axis Value tables: allowing for both ranges & style linking

[Sairus Patel]

Greetings, all.

Here’s a proposal I brought up on the OTFontVar list a month or so ago. (The concern has been discussed on that list before.) I’ve reworked the proposal slightly. There hasn’t been additional feedback in the past few weeks, and I hope we can somehow declare this resolved soon.


=== Background & concern ===

STAT (https://docs.microsoft.com/en-us/typography/opentype/spec/stat#axis-value-tables<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Ftypography%2Fopentype%2Fspec%2Fstat%23axis-value-tables&data=02%7C01%7Csppatel%40adobe.com%7Cc369832a5710496b33ce08d83595765c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637318263352448325&sdata=yQNEPoX8d7CvHEn64kCRSvJqZV1u7mvPoa2Qk30%2BIj4%3D&reserved=0>) says, of Axis Value tables, “No two tables should provide information for the same axis value.”

Perhaps that was intended for Axis Value tables *of the same format*. Certainly there are compelling cases where formats 2 & 3 would be needed or appropriate for the same axis value (example below).

The concern is that at least one font validation tool warns about such fonts due to the above stricture in the spec. It’s conceivable that implementations may reject such fonts or ignore some of their Axis Value tables because of the perceived violation.

Example:

In a variable font, Axis Value format 2 for wght=400 (range 350–450) assigns name “Regular” and format 3 for wght=400 provides the bold style-link (to 700). Adobe has made some variable fonts in this way, and I hear other foundries are doing so as well. I know that opsz was an important use case for format 2, so just to be clear, the idea behind assigning a name to a weight range (just as to an opsz range, though opsz ranges also allow for automatic selection) is allowing apps to choose to make custom instance names more human-readable, e.g. “Wide Light-299” as in Photoshop instead of something like “Wide 299” or “Wide wght-299”, for the case when the user started from the “Wide Light” named instance and reduced the weight by just a single unit. Users shouldn’t be expected to know what numerical weight values mean and apps shouldn’t need to make hard-coded assumptions about UI names: a font should be able to specify these strings. Indeed, specifying such strings are a big part of what the STAT table is about.


=== Solution ===

Replace “No two tables should provide information for the same axis value” with:

[[
No two tables of the same format should provide information for the same axis value or (in the case of format 4) combination of axis values. In the case where different format tables, for formats 1–3, provide information for the same axis value, the value of their flags field as well as of their valueNameID field must be the same. A format 4 table may specify an axis value that is also specified in another table, but only if there is some other difference in the axis values specified by those tables. Note that the term “axis value” in this paragraph refers only to the ‘value’ field in formats 1, 3, and 4, and the ‘nominal value’ field in format 2.
]]

The first & third sentences in the above proposal are based on Peter Constable’s suggestion on the OTFontVar list when I brought up this topic. Peter’s wording addressed the ambiguity around how the stricture applies to format 4 (the stricture hadn’t been revised after format 4 was added to the spec); I added “of the same format” to Peter’s wording in the first sentence in order to address the main concern described in this email.

The last sentence of the proposal clarifies exactly what fields are being referred to in these strictures, based on feedback I received. For instance, we aren’t talking about the range axis value or the linked axis value.


=== Further thoughts ===

There have been some discussions about extending STAT to allow specifying range-based style linking, e.g. style-link anything in wght 350–450 to 700 (e.g. a bold-link button in an app), but this hasn’t been a space which folks seem to be very excited about. Apart from style-linking being seen by some as a legacy concept (despite those bold and italic “buttons” continuing to be central to important platforms), there is the question of whether it should be computationally round-trippable. Naturally the above model of range-to-one won’t allow for computational roundtripping; but even if we tried to specify a from-range and to-range for such a mapping, we’d need to specify how to evenly map the ranges when they are of different sizes, and precision/rounding behavior may cause some headaches. And if the solution to that is to say the document model/format should record the original value so that it could be “toggled” back to, well then computational round-trippability is not needed but rather a concept of “undo”, which the originally desired range-to-one model allows for just fine.

Thus, these efforts haven’t gained much traction, for the above and I’m sure other reasons. So apps will probably continue to do their own thing, especially with regard to style linking of variable fonts. At least we can cleanly allow for style linking of specific important instances in STAT, even if we leave style linking of the rest of the design space unspecified. That’s probably a good enough middle path.

===

John Hudson asked on OTFontVar whether app-side heuristics would be adequate for deriving instance names in the situations we’re talking about instead of specifying them in format 2 ranges (my paraphrase of some of his extensive comments).

Now, I can imagine if format 1 names are present for certain important points on the wght axis, then an app could change names midway between these points (and of course account for axis extremities as well). But this wouldn’t work in this version of Source Sans Variable:

Bold:
        <NominalValue value="700.0"/>
        <RangeMinValue value="650.0"/>
        <RangeMaxValue value="750.0"/>
ExtraBold:
        <NominalValue value="800.0"/>
        <RangeMinValue value="750.0"/>
        <RangeMaxValue value="800.0"/>
Black:
        <NominalValue value="900.0"/>
        <RangeMinValue value="800.0"/>
        <RangeMaxValue value="900.0"/>

Can the designer/font producer be convinced in this specific instance to be satisfied with a midpoint or other heuristic instead, one that won’t yield the same results as the above format 2 ranges? Perhaps. But the point of the STAT table is to allow for the full creative expression of designers in specifying exactly how they want apps to display the names for various interesting parts of the design space.

Even if such a heuristic were adequate for wght, and even if all apps implemented that same heuristic, one must then ask whether apps should apply a midpoint or other heuristic to opsz names as well, instead of using the format 2 valueNameID fields for opsz in STAT. But format 2 valueNameID is specified as defining a “display string” not just for the nominal value but for the specified range.

Thus, we come back to the core issue of either STAT format 2 allows the designer to specify display names for a range or it doesn’t. The answer shouldn’t vary by axis. If format 2 was really intended only for opsz, STAT should have been designed differently (or the opsz info should have been added to the end of, say, the OS/2 table – just kidding! ;^).

(And this doesn’t even get into custom axes, and whether a midpoint heuristic would be adequate for them, which is a question difficult to answer given the nature of custom axes.)

===

There were other grander thoughts as well of reinventing the STAT table to allow for incrementally adding properties among formats (rather than adding a new format that was a combination of 2 and 3), but at this point I think removal or softening of the stricture as in the proposal above is the most practical way to move forward, given the situation. Yes there is the infelicity of specifying that the redundant flags and valueNameID must be the same (sentence 2 of the proposal), but for an OT table that’s now been in the works for about half a decade, that’s a small concession to make, all said and done!

Sairus

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