This reverts commit 690080b14d9a4f193092ffc172a39b3e212d307c.
We keep 16-bit GlyphIDs for COLRv1 tables, at least for now
https://github.com/googlefonts/colr-gradients-spec/pull/24
I keep the GlyphID32 converter in case we may need it in the future.
Fix for #1985:
* ensure that the AxisNameID in the STAT table is not less than 256. This needed an additional argument to the addMultiLingualName() name table method.
* fvar axis name IDs must also not be less than 256, just like STAT axis names.
_getUnicodeRangeSets used to calculate sets containing lots of numbers, only to
get intersections between a set and ranges. Creating and manipulating a lot of
big sets requires a lot of memory.
The function has been replaced by _getUnicodeRanges, returning a list of range
starts boundaries and a list of range stops + corresponding bits.
Tests on intersectUnicodeRanges save about 130 MB (!) of RAM, with no
significant speed penalty.
* when reading from binary, name.string may be an encoded bytes sequence: we should call toUnicode() before we compare to the requested string
* fix expected output
* add nameTable.findMultilingualName(), to find an existing multilingual name
* Make addMultilingualName() reuse nameIDs if possible when asking for a new nameID, by calling findMultilingualName()
in COLRv1 all scalar values have associated varIdx to support variations. I want to load them as
immutable namedtuples, and also I want to dump them as simple XML tags with 'value' and 'varIdx'
attributes, instead of normal otTables (i.e. with nested Value and VarIdx sub-elements) as
that would make them too verbose in the XML dump.
So I made a custom _NamedTupleConverter, as a base class for VariableScalar, etc.; sub-classes
must provide a tupleClass and a list of converterClasses for each namedtuple field.
The ExtendMode enum has also a custom converter to dump it as string in the XML, and load it
as IntEnum.
fixup
Fixes https://github.com/fonttools/fonttools/issues/1556
When a component uses firstPt/secondPt reference anchor points instead of XY offsets,
and the component also has a transform, fonttools is incorrectly computing its bounding box.
This is because we are computing the translation offset between firstPt and secondPt before
applying the 2x2 scale/rotation/shear transform. By the time we do the translation, the
offset is now incorrect.
We need to compute the translation offset after we have applied the 2x2 transform.
