OpenType 1.8.2 released

Peter Constable

We've just published another minor-version update of the OpenType spec: OpenType 1.8.2.

This update was primarily aimed at refinements related to OpenType Font Variations, but there were other non-variations-related changes as well.

Significant improvements:

- Axes of design variation (weight, width, etc.), previously described in the 'fvar' chapter, are now described in a dedicated set of pages, the OpenType Design-Variation Axis Tag Registry. This was done because these are relevant for non-variable as well as variable fonts, and to facilitate registration of new axis tags in the future.

- 'fvar': A new axis flag has been defined, HIDDEN_AXIS. This was defined to allow new font-picker user interfaces in applications to anticipate this or other future flags that may provide recommendations on how to present font options in the UI.

- 'gvar': The "IUP" algorithm (for inferring deltas for in-referenced points) has been revised to cover specific cases that were undefined, leading to inconsistent behaviours across platforms.

- 'STAT' (now version 1.2): Added a new axis value table format, format 4, which will allow named instances of some variable fonts to be supported better in older applications that were not designed to support families with an open-ended set of axis possibilities.

- CFF2: The FontMatrix operator has been constrained, and restricted to use in a Top DICT only.

- OT Layout scripts/language systems: A constraint on use of language system tags with 'DFLT' script has been relaxed.

There were also several errors corrected and details clarified, as well as many editorial changes, including changes to structure or field names for better consistency across the spec.

For more complete details on changes, see the change log.

A note to font tool developers: all but a few chapters were revised to include anchors for all sections, table/record/enumeration descriptions, and individual fields, allowing you to offer users links to very specific parts of the spec.

John Hudson

- OT Layout scripts/language systems: A constraint on use of language system tags with 'DFLT' script has been relaxed.

Where is this in the update, Peter. I see that the final text on the script registry page still says: 

When the ScriptList table is searched for a script, and no entry is found, and there is an entry for the 'DFLT' script, then this entry must be used. Furthermore, the Script table for the 'DFLT' script must have a non-NULL DefaultLangSys and a LangSysCount equal to 0; in other words, there is only a default language for the default script.

Theunis de Jong

John, that page is not in the most recent update list (it's still dated April 2017, not July as they others are). I think this is mentioned on the Common Tables page:

A Script table with the script tag 'DFLT' (default) may be used in a font to define features that are not script-specific. An application should use a 'DFLT' script table if there is not a script table associated with the specific script of the text being formatted, or if the text does not have a specific script (for example, it contains only symbols or punctuation). [my emph.]

In 1.8.0 it reads

If a Script table with the script tag 'DFLT' (default) is present in the ScriptList table, it must have a non-NULL DefaultLangSys and LangSysCount must be equal to 0. The 'DFLT' Script table should be used if there is not an explicit entry for the script being formatted.

So, the relaxed constraint would be that if a certain feature is not found in a specific script/language pair, a second search should be done in 'DFLT'.

Nice -- that means no more unnecessary duplication of features! On the other hand, if you want your font's features to be supported even with "older" software (that is, per July 2017), you can't use this.

Peter Constable

@John Hudson, I wasn't aware of that statement at the bottom of the script registry page. Theunis has located the relevant change. We'll need to revise the script registry page at some point.

Peter Constable

@John Hudson: We've published an erratum for this in OT 1.8.2. Thanks for bringing it to my attention.

Belleve Invis

@Peter Constable
I have a question about VVAR: if the point being topmost of a glyph changed after applying a delta, then either TSB or VOrg is not representable in the "value + delta" mechanism. How can we solve this? Prioritize VOrg?