This updates fonttools to match the latest draft COLRv1 spec at https://github.com/googlefonts/colr-gradients-spec/pull/290
Summary of changes:
- Added 8 new PaintScale* tables: with/without centers, uniform vs non-uniform
- Added *AroundCenter variants to PaintRotate and PaintSkew (default versions no longer have centerX/Y defaulting to origin)
- PaintRotate, PaintSkew and PaintComposite formats re-numbered
This is a breaking change (but the COLRv1 API was already marked as unstable and subject to change)
The changes in this PR are meant to match the changes from the COLRv1 draft spec at:
https://github.com/googlefonts/colr-gradients-spec/pull/302
* Replaced all from ...py23 import * with explicit name imports, or removed completely when possible.
* Replaced tounicode() with tostr()
* Changed all BytesIO ans StringIO imports to from io import ..., replaced all UnicodeIO with StringIO.
* Replaced all unichr() with chr()
* Misc minor tweaks and fixes
When a TTFont is loaded with lazy=True, the otTables are only loaded upon BaseTable.__getattr__
when the requested attribute is not found in the instance __dict__.
Since the Paint.Format enum was defined at class level, every Paint instance, even when loaded
lazily, will have a 'Format' attribute and the magic decompile-on-missing-attribute will not
trigger, since the class attribute will be returned when the instance is missing one.
For this reason, and to not add further special cases, it's better to simply move this Paint.Format
enum class outside to the module level scope, and rename it PaintFormat.
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
If offset overflow happens other than between Lookup and SubTable, or
within SubTable, then we don't know how to fix it currently. Now we
try to put that lookup in an Extension lookup anyway, since that will
isolate it and sharing with other lookups won't happen, hopefully
avoiding the overflow.
This is really a bandaid... What we want is the 99proof branch to
be finished and replace our current packing algorithm.
Fixes https://github.com/fonttools/fonttools/issues/1296