Using TTFont.getGlyphOrder() would also require to decompile post and cmap tables.
But we don't need the actual glyph names in order to apply the WOFF2 glyf transform.
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...
Reorder to OT spec recommended order if reorederTables == True (default).
Don't reorder if reorderTables == None.
Keep the input font original table order if reorderTables == False (and
the font has a reader object from which to get the original order).
when _getGlyphNamesFromCmap gets called by the cmap parser itself, the
partially loaded subtable is removed and then restored later.
However, when a TTFont instance is imported from XML rather than from
binary file, its 'reader' attribute is None, and so the line:
tempcmap = self['cmap'].getcmap(3, 1)
will make TTFont.__getitem__ raise KeyError. It's better to fail nicely,
and return a dummy glyphOrder based on maxp numGlyphs.
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.
