Towards addressing https://github.com/fonttools/fonttools/issues/1070
The new instantiateVariableFont function takes a variable TTFont and a
dictionary of axes locations and returns a static TTFont instance.
The current code modifies the varfont in-place. To adapt it for
generating multiple instances from the same varfont, for now I simply
resorted to making a copy (can be optionally disabled by setting
inplace=True).
Also, replaced print() with log.info().
Instead of raising AssertionError when users define custom axes
without explicit `<labelname xml:lang="en">ZZZZ</labelname>` element,
it's better to use the axis' name attribute, and treat it as "en"
language.
For example, if users generate the designspace from SuperPolator,
they can't edit the axis labelname attribute from the UI (or maybe
it's just me that couldn't figure out how to do it).
We need to use float (0.) rather than int (0) for the normalized axis
origin, otherwise some varLib roundtrip tests may fail.
E.g.
```diff
<tuple>
- <coord axis="wght" max="1.0" min="0.0" value="0.61"/>
+ <coord axis="wght" max="1.0" min="0" value="0.61"/>
```
This is a follow-up to Jens' comment:
19c4b377b8 (commitcomment-23458151)
Now, if there's any axis that has 'interesting' segment maps (and thus
an avar table is added), we also ensure that for the rest of the axes
that aren't modified (either because no <map> elements are defined or
because an identity mapping is defined in the designspace), we always
have a non-empty segment maps array containing the three default maps:
{-1.0: -1.0, 0.0: 0.0, 1.0: 1.0}.
This is to work around CoreText and DirectWrite rendering issue with
empty avar segment maps arrays.
* Initialize the avar segment map with required default entries
* Set default values only after deciding that a segment map is needed for this axis
* Correct dict update call
Pass a maximum lookback of n to the circle-breaking DP of size 2*n.
This should theoretically speed up that DP by a factor of 4 or 8 or something...
Empirically it's far from that, but solidly measurable.
Again, gvar table size got a slight improvement, which I didn't expect... It
might be that my one test is hitting lucky cases with point encodings.. or it
might be just me wishfully thinking so.
Drives it into acceptable speed now. Note that I'm getting better
gvar size after this patch, which I didn't expect. So, either this
algorithm or the previous one was buggy. :(
Previously, it was always encoding first and last point. Now it only always
encodes last point. Soon resolving that too. Shows another 0.5% savings in
gvar table size with Noto Sans Arabic.
This reverts commit 3e35441c805b03d6d6eea5b24ce44f555c5fad56.
The DP is cleaner to work out front-to-back.
Will achieve the same effect by flipping the lists in a later commit.
