NameRecord.__str__ returns a unicode string, but on Python2 the built-in str()
expects a bytestring, therefore it raises
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-1: ordinal not in range(128)
We should probably change that as well.
If the referenced name record already exists, the string is modified in place.
If it doesn't exist, a new record is created with the given IDs and string.
If nTracks == 0, nSizes is also == 0, the `else` part is sufficient.
There's a limit case when nTracks can be > 0, and nSizes == 0, but it's
unlikely or useless.
This should make the unit tests more readable, and it also prevents
failures where a changed fromXML() implementation fails to ignore
interspersed whitespace. This has recently caused some developer
nuisance; see https://github.com/behdad/fonttools/pull/367.
Instead of having a custom parser implementation, it would be nicer
to call the actual XMLReader. However, XMLReader has a deeply built-in
assumption that it is processing an entire TTX file. Changing this
assumption would certainly be possible, but it would need a re-write
of the XMLReader code; having a custom parser just for unit tests
seems less involved.
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.
