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.
We can't set, e.g. `__radd__ = NotImplemented` as it's not a callable.
NotImplemented is what is returned from a rich comparison method
when self doesn't know how to compare with the other object.
_LazyList object may also occur on the right hand side of a `+`
operator, when the left operand is a list. Also in this case we
want to first unpack the _LazyList and return a new list containing
elements from both.
this adds three new tests for varLib.build:
1) the input designspace contains a single 'weight' axis with <map>
elements that modify the normalization mapping;
2) the input designspace contains two 'weight' and 'width' axes both
with <map> elements, but the 'width' axis only contains identity
mappings;
3) the input designspace contains two 'weight' and 'width' axes, but
only one axis ('weight') has some <map> elements.
The master interpolatable ttx files for 'TestFamily3' are a subset of
Noto Sans containing only the letters to type the word "FontTools".
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.
Otherwise dumping avar table to TTX after it's been generated by
varLib could produce different float strings than when dumping the
same avar table after compiling and decompiling.
We need to use float (0.) rather than int (0) for the normalized axis
origin, otherwise some varLib roundtrip tests may fail.
E.g.
```diff
<tuple>
- <coord axis="wght" max="1.0" min="0.0" value="0.61"/>
+ <coord axis="wght" max="1.0" min="0" value="0.61"/>
```
This is a follow-up to Jens' comment:
19c4b377b8 (commitcomment-23458151)
Now, if there's any axis that has 'interesting' segment maps (and thus
an avar table is added), we also ensure that for the rest of the axes
that aren't modified (either because no <map> elements are defined or
because an identity mapping is defined in the designspace), we always
have a non-empty segment maps array containing the three default maps:
{-1.0: -1.0, 0.0: 0.0, 1.0: 1.0}.
This is to work around CoreText and DirectWrite rendering issue with
empty avar segment maps arrays.
After this change, fonttools is able to dump the `lcar` table of
the AppleChancery font to XML. However, the resulting XML cannot
be compiled back to TrueType, yet. So, something is still broken
with the implementation of AAT lookups. Need to do more testing
before the support for table `lcar` can be added to fonttools.
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.
