In the upcoming draft of COLR spec, PaintSweepGradient's startAngle/endAngle are encoded with a +1.0 bias to allow for representation of a full +360° positive angle. Normal F2Dot14-fraction-of-half-circle angles can only represent angles between -360 <= angle < +360
This is a breaking change and will need to be coordinated with rendering implementations (at least FreeType/Skia).
4294967295 (0xFFFFFFFF in decimal form) is not very memorable.
Still, using hex notation for all VarIndexBases would make the non-default values less readable (when interpreted as an index into the DeltaSetIndexMap array, decimal makes more sense).
Since 0xFFFFFFFF means 'no variation data', it makes sense to omit it from the ttx dump and write an empty <VarIndexBase/> element with no value.
We also allow to build Var tables without needing to pass "VarIndexBase": 0xFFFFFFFF in the source dict.
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
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.
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
