In OT kern subtable header, the format is the high byte of 'coverage'
bit mask (bits 8-15), and the low byte (bits 0-7) is the actual coverage
bits.
In AAT kern, it's the opposite: the coverage flags are the high byte,
whereas the subtable format is the low byte.
Also adjusted the test data, and set coverage to 1 for OT kern subtable
(which means the usual horizontal kerning).
Beyond composing ligatures, AAT finite-state transducers can also
execute insertion actions without rewriting existing glyphs. The
corresponding actions have almost the same structure as ligature
actions, so we can share a lot of the plumbing within fonttools.
This renaming is in preparation of a larger change to support `morx`
ables with insertions.
Before this change, we were emitting XML with numeric values for `morx`
coverage flags. Now, we emit XML that makes more sense to human readers.
XML files from previous versions of fonttools can still be parsed.
The hexdump in the specification is wrong, but the correct value
is in the comments. Before this change, the finite-state transducer
in our test data could be decompiled but would not implement the
behavior explained in the AAT specification.
The XML output for other tables is also sorted alphabetically
by glyph name, not by glyph order.
This reverts commit c77e9fe12d5879aeb79c05f8ececebb3275524b7.
Before this change, the AAT lookups were alphabetically sorted by glyph name,
but it seems more natural to write XML in the usual glyph order. No changes to
the binary format (which already was in glyph order); this only affects how
XML output is produced.
The AAT `ankr` anchor point table is an auxiliary table for `kerx`,
used to store anchor overrides in case the glyph itself does not
supply the needed anchors as control points. Among the fonts that
come pre-installed with MacOS 10.12.6, `ankr` is used by a handful
of non-Latin fonts such as “Myanmar MN”, “Devanagari Sangam MN”,
and “Arial HB”.
https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6ankr.html
Other metamorphosis types are not yet supported and will raise an error
upon decompilation. The TTX tool catches the error and continues to emit
a hexdump of the table contents, just as before this change.
Interestingly, this can handle the examples from the AAT specification
(which are part of the unit tests), and also most AAT fonts on my disk.
However, some other AAT fonts such as Apple Chancery cannot be decompiled.
The failure seems to be a general problem with how fonttools decompiles
AAT lookups of format 4, and unrelated to this present change.
In format 2 and 6, AAT lookups contain a binary search header with
the number of elements in the lookup table. Before this change, the
element count would also include the special trailing end-of-table
value that is required by the font format specification. However,
the binary search header should only count the actual elements
without the trailer.
Also, in the examples from the AAT specification, the special
end-of-table entries use 0xFFFF for glyph ID keys, and zeroes
for the filler values. Before this change, we had filled the
values with 0xFF bytes.
Before this change, the code assumed that all values of AAT lookups
get internally represented as strings, which is correct for GlyphID
values but not generally the case.
Also renaming the XML element from `Substitution` to `Lookup`
because AAT lookups have other uses beyond glyph substitutions.
Before this change, the decoder would silently remove "redundant" values
when decompiling AAT lookups. However, it is perfectly valid for a lookup
to map a glyph ID to itself, and also not all AAT lookups have glyph IDs as
their value range.
With AAT, the same lookup data structure can be used for various
types of values. In the morx table, the values are glyph IDs or
glyph classes, which both are encoded as 16-bit unsigned integers.
In other AAT tables, however, the values can be different data types
with different encodings. By passing a `valueWriter` callback and
explicit `valueSize`, we prepare for eventually templatizing
the building of AATLookups.
Also, assert that the called writer wrote the exact number of bytes
that was predicted when figuring out what format should be used for
encoding an AATLookup.
