When the lexer encounters the "include" keyword, it now enters
a special mode for scanning file names. After having scanned over
the file name, the lexer goes back to normal. The exact format
of file name strings is not defined by the OpenType feature file
specification, so we accept any character that is not a closing
parenthesis.
This simplifies the implementation of the parser for
OpenType feature files, since it can now just keep
token locations returned by the lexer. Before this
change, the parser had to un-pack the location tuples
and build new tuples that included the file path.
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.
If no "encoding" argument is provided to Python3 `open`, the default plaftorm's encoding (cp1252 on Windows) is used when decoding bytes to unicode strings.
So, we use the `io.open` function (i.e. a backport of Python3 default file interface) with `encoding="utf_8"` argument.
Fixes https://github.com/behdad/fonttools/issues/323
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.
