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)
- changed getCoordWidth method to use all if-stmt, ordered by ret value (0, 1, 2).
- added more info to TypeError message in getCoordWidth method.
- in round/scaleDeltas, chained if statements in one line to avoid writing the loop twice.
since we use pytest-randomly to randomize the test execution, depending on when
this specific test is executed, it may have the side effect of configuring
the global logging configuration, causing other tests that capture logging
messages to fail.
E.g. see https://travis-ci.org/fonttools/fonttools/jobs/545680550
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.
Also, the TTFont.getGlyphOrder() automatically makes up a dummy
glyph order from the maxp.numGlyphs, we simply need to ensure
'maxp' is decompiled before 'glyf'.
When transforming glyf, the glyf.glyphOrder is guaranteed to
be present (as the glyf table has been already decompiled), so
we don't need to deal with it being missing or incorrect
(hence removed spurious tests).
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.
After partial instancing, multiple FeatureVariationRecords may end up with
the same set of conditions (e.g. if one references two axes, one of which
is dropped, and a subsequent one also references the same axis that was
kept in the preceding record's condition set, and the min/max values are
the same for both records).
Therefore, we make sure only the first unique record with a given
configuration of conditions is kept. Any additional records with identical
conditions will never match the current context so they can be dropped.
ConditionTable.AxisIndex needs to change when dropping axes, to
refer to the same axis in the modified fvar.axes array.
There was also another bug when a condition was not met,
and the `applies` flag (initialised to `True`) was not set to
`False`, thus substutions were incorrectly applied.
the buildGSUB function creates an empty GSUB with no FeatureRecords, so the
FeatureIndex list should be empty initially; the index of the newly created
rvrn feature record will be appended later on by addFeatureVariationsRaw
function.
