Even if HVAR no longer contains any variations, it's better to keep it because
otherwise one would have to check the glyphs' phantom points to confirm that
the advance widths (or heights for VVAR) don't vary
The current method for L1 and L2 partial instacing of STAT table --
i.e. drop all pinned axes are respective axis values -- was incorrect.
STAT design axis are a superset of the fvar axes, they describe the relations
between members of a font family in which some aspects may be implemented as
variation axes within a single VF, others as multiple discrete fonts.
When we remove an axis from fvar, we still want to keep the STAT's DesignAxis,
as well as the single AxisValue table along that design axis which describes
the position of the new instance within the family's stylistic attributes.
This means, intantiateAvar will never drop any DesignAxis, but will only drops
AxisValue tables when: 1) we're pinning an axis and the desired instance
coordinate doesn't exactly equal any of the existing AxisValue records;
2) we're restricting an axis range, and the (nominal) AxisValue falls
outside of the desired range.
We never add new AxisValue records, as that's a design decision that
is outside of the scope of the partial instancer.
Added method to limitTupleVariationAxisRanges which takes a map of
axis tags to (min, max) ranges and drops entire deltasets when outside
of the new limits, or scales the ones that are within range.
Modified _TupleVarStoreAdapter to account for the fact that, when limiting
axes, existing regions can be modifed rathern than simply dropped
(see rebuildRegions).
Implemented limiting axis ranges for fvar, FeatureVariations, and avar.
Note how we pass user-scale coordinates to instantiateAvar, because we need
both the default normalized coordinates and the ones mapped forward (by
the very same avar table that we are instancing).
STAT table support will follow in a separate commit.
* varLib.cff: Apply conv_to_int() to all the values
* varLib: Don't hardcode file extension to 'ttf'
Also remove unused imports
* varLib.cff: Fix merging of sparse PrivateDict items
Fixes#1651
When building a variable font, varLib.build must make sure that
the OS/2.usWeightClass is equal to the wght axis default location,
that the OS/2.usWidthClass is set to the equivalent value (1-9) of
the wdth axis default location, and finally that post.italicAngle
is set to the same default value as slnt axis.
Sometimes the base master doesn't have these values correctly
set leading to discrepancies between OS/2 and post, on the one
hand, and the fvar axes' default values.
isPairPos and isSinglePos are mutually exclusive and isSinglePos is only defined if isPairPos is False
so it is safe to use it in 'else' or 'elif' branches (logical expressions short-circuit)
When a SinglePost lookup is compiled, pretty much all compilers do some compression by combining similar ValueRecords into a single subtable. This compression produces different lengths of the list of subtables between source fonts. The original code required that all SinglePos lookups have the same subtables, often doesn't work.
I fixed this in varLib.merger.py by first flattening a SinglePos lookup to a single subtable, using the same record format for all records, and then merging the source fonts. After the merge is complete, I call fontTools.otlLib.builder.buildSinglePos() to rebuild the lookup subtables.
Previously we were calling glyf.setCoordinates method only when a glyph had some
variation deltas to be applied to the default glyf coordinates.
However, some composite glyph may contain no variation delta but their base glyphs
may change, thus we still need to update the sidebearings and bounding box of the
composite glyphs.
continue checking subsequent condition tables in case the other may
be format=1 and may reference a pinned axis; in which case, these
conditions need to be dropped from the condition set, or the whole
record needs to be dropped if the instance coordinate is outside the
condition range.
Condition tables within a condition set are associated with a AND
boolean operator, so if any one doesn't match, the whole set doesn't
apply. Even if we don't recognize one condition format, if we do
ascertain that another condition table does not match the current
partial instance location, we can drop the FeatureVariation record
since it doesn't apply.
this is done automatically upon compiling; however it's good to do it here
as well, in case one wants to pass the updated font directly to other modules
like 'subset' which requires these fields to be present -- without having
to first compile and decompile.
there was a logic issue in the function that checks whether a FeatureVariationRecord
has a unique set of condition (was returning False instead of True for unsupported condition).
It's safer to always keep such records with unknown condition formats as new formats
may be added in the future. A warning is already issued in these cases.
