Before this change, the XML output for GSUB lookups of type 3
was not deterministic; multiple runs of TTX on the same font
could therefore emit the alternates in a different order.
Since alternate glyphs are sets, this change makes no semantic
difference to the output. However, a deterministic ordering
is needed for tests that compare GSUB tables in TTX format.
When a font supplies no glyph names in its 'post' table, fontTools
builds synthetic glyph names by reversing the 'cmap' table.
After this change, the library looks at all 'cmap' subtables for
Unicode, irrespective of format or platform. For example, glyph #4
in NotoSansOldItalic-Regular.ttf gets now named "u10300" instead of
"glyph00004".
Moved the code for building a reversed 'cmap' table into the cmap class,
for easier testing.
The data-structure can be used in more places, but it's most beneficial in
this table since hdmx tables can have tens of ppem's, each having a dictionary
keyed by glyphnames...
Because I could not find any fonts with “dlng” (design languages) or
“slng” (supported languages) sub-tables, these are not implemented yet.
We could easily implement them according to spec, but it is unclear
to what extent the spec is matching reality.
Fixes https://github.com/googlefonts/fontbakery/issues/551
the `codes` variable needs to be a sorted list of cmap keys, else the following line
```python
codes = range(codes[0], codes[-1] + 1)
```
cannot work properly, since dict keys are unsorted.
Up until 13a08d0c3a59402459875155b7dbd194787fb229, there was a line with
```python
codes.sort()
```
which was deleted for some reason.
Was "broken" in the performance work in commits
8724513a67f954eac56eeb77ced12e27d7c02b6b and
1d93f9099de4987c5c7d7e49a23f4c46a45dfab2.
Use slow method if exception raised.
The changes should move to TTFont layer itself. I'll move them
in a separate commit.
There now is a Python implementation of variation axes, because this
makes it (much) easier to build variable fonts from code. Therefore,
the definitions in otTables.py are not needed anymore.
In the previous table-driven implementation, client code had to
know the internals of the ‘fvar’ structure for correctly adding
variation axes to a font. In the new implementation, clients
do not have to futz around with binary offsets (which makes it
more likely that tools build correct fonts).
Useful for generating XML comments when tables refer to name IDs.
For example, XML for a named instance in an ‘fvar’ table is easier
to read when it says <!-- Bold --> in addition to nameID="258".
Previously, if a subtable's data was shared amongst two different encodings,
the second one being loaded was getting a cmap member assigned while retaining
its data item. If we subset the cmap and then save that subtable, the original
unsubset data will be written out. Fix, but removing data when assigning cmap.
Explains and obviates mystery hack in subsetter.
