Resolves https://github.com/behdad/fonttools/issues/355
For making sure that `pyftsubset` still works after this change,
I have done the following steps:
* invoked Adobe's `makeotf` tool to build a custom font with a
MultipleSubst lookup. This lookup decomposes two two ligatures,
`c_t` and `f_f_i`, into their respective components.
* invoked the `pyftsubset` tool to produce a subset font with just
the `c_t` ligature;
* checked with `ttx` that the newly produced subset font contains
the requested `c_t` ligature and its components `c` and `t`,
but does not contain not any of `f_f_i`, `f`, or `i`.
Before this change, TTX (when running in Python 2.7) would fail
to compile a font if the input contained an `ltag` section.
With Python 3, it worked perfectly fine even before this change.
Resolves https://github.com/behdad/fonttools/issues/357
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.
