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

Thu Aug 27 04:04:28 CEST 2020

Thanks Sairus for sharing this!

I'd like to invite you to post it as an issue on
https://github.com/MPEGGroup/OpenFontFormat as it's clearly actionable :)

On Wed, Aug 26, 2020, 8:06 PM Sairus Patel <sppatel at adobe.com> wrote:

> 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
>
>
> _______________________________________________
> 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/20200826/a5a61516/attachment-0001.html>