<div dir="auto"><div>Thanks Sairus for sharing this!<div dir="auto"><br></div><div dir="auto">I'd like to invite you to post it as an issue on <a href="https://github.com/MPEGGroup/OpenFontFormat">https://github.com/MPEGGroup/OpenFontFormat</a> as it's clearly actionable :)</div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Aug 26, 2020, 8:06 PM Sairus Patel <<a href="mailto:sppatel@adobe.com">sppatel@adobe.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="m_5387485326841881577WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Greetings, all.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">=== Background & concern ===<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">STAT (<a href="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" target="_blank" rel="noreferrer">https://docs.microsoft.com/en-us/typography/opentype/spec/stat#axis-value-tables</a>)
says, of Axis Value tables, “No two tables should provide information for the same axis value.”<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Example:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">=== Solution ===<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Replace “No two tables should provide information for the same axis value” with:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">[[<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.
</span><span style="font-size:11.0pt;color:black">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.
</span><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">]]</span><span style="font-size:11.0pt"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">=== Further thoughts ===<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">===<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">John Hudson asked on OTFontVar whether app-side
</span><span style="font-size:11.0pt;color:black">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).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">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:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Bold:</span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <NominalValue value="700.0"/></span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <RangeMinValue value="650.0"/></span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <RangeMaxValue value="750.0"/></span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">ExtraBold:</span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <NominalValue value="800.0"/></span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <RangeMinValue value="750.0"/></span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <RangeMaxValue value="800.0"/></span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">Black:</span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <NominalValue value="900.0"/></span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <RangeMinValue value="800.0"/></span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <RangeMaxValue value="900.0"/></span><span style="font-size:8.5pt;font-family:Menlo;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">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 “</span><span style="font-size:11.0pt;color:#171717;background:white">display string” not just for the nominal value but for the specified
range.</span><span style="font-size:11.0pt;color:black"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">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! ;^).<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black"> <u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:black">(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.)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">===<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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!<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Sairus<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><u></u> <u></u></span></p>
</div>
</div>
_______________________________________________<br>
mpeg-otspec mailing list<br>
<a href="mailto:mpeg-otspec@lists.aau.at" target="_blank" rel="noreferrer">mpeg-otspec@lists.aau.at</a><br>
<a href="https://lists.aau.at/mailman/listinfo/mpeg-otspec" rel="noreferrer noreferrer" target="_blank">https://lists.aau.at/mailman/listinfo/mpeg-otspec</a><br>
</blockquote></div></div></div>