[OTVar] OpenType 1.8.1 released

Peter Constable

We've just published a new minor-version update of the OpenType spec: OpenType 1.8.1. This update was primarily aimed at refinements related to OpenType Font Variations, but there were a few non-variations-related technical changes, and we also used it as an opportunity for certain editorial improvements.

The significant technical changes are the following:

- Various technical corrections already noted as OT1.8 errata were incorporated.

- In the 'fvar' table, the countSizePairs field was, in effect, a redundant versioning mechanism. This field has been changed to permanently reserved, and implementations are not expected to use it to determine how to read the table.

- Also regarding the 'fvar' table, expected behaviour was spelled out for the cases of having axisCount = 0 (font is not treated as a variable font) and instanceCount = 0 (there is still one named instance).

- In the MVAR table, the axisCount field in the header was redundant. This field has been changed to permanently reserved.

- Cleanup of the CFF2 and CFF2 CharString chapters included correction of various technical errors, removal of the unused Boolean operand type, and other changes. (These chapters underwent a lot of revision, and I don't have exact details on how many changes might be considered technical changes.)

- An additional field was added to the STAT table, now version 1.1. The 1.0 STAT table (without the additional field) is deprecated.

- Also related to the STAT table, interpretation rules have be added for the case in which format 2 axis value tables for a given axis have overlapping ranges.

- The version 5 OS/2 table added the usLowerOpticalPointSize and usUpperOpticalPointSize fields for families with optical size variants. This mechanism is now superseded by the STAT table. For now, these OS/2 fields are not yet deprecated, but use of the STAT table for this purpose is recommended, and we'd like to deprecate these OS/2 fields in the future.

- In the discussion of the GETVARIATION instruction, "NPUSHB" was corrected to "NPUSHW".

- In OT1.8, we introduced a convention of replacing a single Fixed table version number field with a pair of major/minor version fields. That was applied in OT1.8 only to tables already being touched; in OT1.8.1, this was extended across all tables for which it was possible. (For certain tables, such as 'post', minor numbering with Fixed has been done in a manner that doesn't really allow separating into separate major/minor fields.) In the future, we won't use Fixed for version numbers in any new tables.

- In OT1.8, there were conflicting statements as to whether tables must start at 4-byte-aligned offsets. This is now consistently stated as a requirement.

- Added OpenType Layout language system tags for Eastern Cham and Western Cham.


A couple of things that is mostly editorial / marginally technical have to do with field names and data types. A handful of field names in various tables were changed for better consistency. A much broader change was in data type conventions:

- For fields containing subtable offsets, the data types are now always Offset16 or Offset32.
- The use of Windows data types CHAR, BYTE, SHORT, etc. has now been globally replaced with less ambiguous types: uint8, int8, uint16, int16, uint24, uint32, int32.
- Removed FUNIT and GlyphID as data types. (FUNIT was not actually used anywhere as a data type, and GlyphID had been used only in a limited number of places but not in obvious places such as the 'cmap' and 'glyf' tables.)

If you look at the change log, the majority of changes recorded are these data type changes. In terms of the number of pages touched, this will probably be one of the largest changes in the OpenType spec for a long time.

SiDaniels

Thanks Peter and also to Aaron for getting this live. :-)

Belleve Invis

What about the problem that in CFF2 you can “Blend” a subroutine index?

Peter Constable

@Belleve Invis : I'll need to get Adobe folk to respond.

Read Roberts

Unfortunately, blending a subroutine index is not forbidden in the 1.8.1 CFF2 CharStrings chapter. The intent is in fact to allow blending of only coordinate values. This follows from a higher level principle that we want to always be able to convert a set of outlines between TrueType and CFF2 CharStrings, and hence do not want to allow operations in CFF2 Charstrings that cannot be supported in TrueType. There was a sentence which stated this in most versions of the 1.8.1 working draft, but it got lost by accident before the final version. At this point, it will have to wait for the 1.8.2 update, but this restriction will go back into the spec.

Belleve Invis

Read Roberts said:

Unfortunately, blending a subroutine index is not forbidden in the 1.8.1 CFF2 CharStrings chapter. The intent is in fact to allow blending of only coordinate values. This follows from a higher level principle that we want to always be able to convert a set of outlines between TrueType and CFF2 CharStrings, and hence do not want to allow operations in CFF2 Charstrings that cannot be supported in TrueType. There was a sentence which stated this in most versions of the 1.8.1 working draft, but it got lost by accident before the final version. At this point, it will have to wait for the 1.8.2 update, but this restriction will go back into the spec.

And CFF2 allows that you can re-use a blended result as a parameter of another blend operator, which introduces non-linear interpolation that TT’s GVAR cannot support.
And maybe you guys should provide some library to perform topology-preserving outline format conversion, esp. cubic → quadratic.

Read Roberts

Dave Arnold points out that the statement is in the 1.8.1 CFF2 CharString spec, just not where I remembered it. It is in section 3.1: "

Blend operators may not be nested. Hint mask bytes and subroutine indices may not be blended."