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).
this will be useful when computing deltas for COLR table fields that use Fixed or F2Dot14 (ItemVariationStore internally treats fixed-value floats as 16 or 32-bit integers)
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.
* 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
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
Beyond composing ligatures, AAT finite-state transducers can also
execute insertion actions without rewriting existing glyphs. The
corresponding actions have almost the same structure as ligature
actions, so we can share a lot of the plumbing within fonttools.
This renaming is in preparation of a larger change to support `morx`
ables with insertions.
Before this change, we were emitting XML with numeric values for `morx`
coverage flags. Now, we emit XML that makes more sense to human readers.
XML files from previous versions of fonttools can still be parsed.
Since the AAT ligature subtable does not encode the number of ligature
glyphs, we need to infer this from the total structure length. We pass
this around by creating a custom sub-reader that only has the substruct
as its data. There might have been easier ways to accomplish this, but
we should anyway change the XML output for MorxSubtables to use custom
flag names, similar to what we're already doing for flags of morph actions.
Having a custom converter for MorxSubtables is in preparation for that
later XML format change.
