Nothing clever, if the source font has a CFF2 table use it as if it were
a CFF table (i.e. non-variable, not sure what would happen in the source
CFF2 was variable already).
The SingleMaster.designspace contains only one source master, so there is no real
variation data.
Still, and empty HVAR table is added (with RegionAxisCount == fvar.AxisCount).
The gvar and cvar table are not added in this case, since they are empty and
not required.
* 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.
We assert that the composite glyph's sidebearings and bbox are updated when its parent glyph
has changed.
The tests will fail, but a fix will follow shortly.
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.
instead of reading off existing FeatureVars.ttx test file.
This gives us more flexibility to add more tests, and keeps the input
values closer to the expected results
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.
