* cleanup cmap format 14 TTX format by removing redundant attributes
* don't output the name attr for a default mapping, instead of a glyph named 'None'
* still accept 'None' as an indicator glyph name, for bw compatibility
* swap order of TTX attrs uv and uvs
* make sure (unicode, glyphName) pairs are always tuples in uvsDict.
gid=0 means "not mapped". Many of the cmap formats use this to
optimize byte encoding. When reading these tables, we don't
want to map charcodes to gid0 in the resulting struct.
self.data is usually set by decompileHeader as "the data after the header"; while here
it also included `headerdata`. This produced corrupt data if the compile method was called
again, as the header data is added again to self.data.
Moreover, in none of the subtable classes' `compile` methods, the re-compiled data is
stored in self.data, so we shall not do that for format 14 either.
Fixes#389
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.
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.
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.
Apparently these days these tables are used to encode symbols in
PUA, so they are still Unicode-compatible...
This follows a similar change in fontconfig.
