The items() of self.markFilterSets_ dictionary are not guaranteed to be always
ordered the same (may vary across python implementations or on subsequent runs).
To ensure deterministic order of Coverage subtables in MarkGlyphSetsDef tables,
we sort the mark sets by the order in which 'UseMarkFilteringSet' statements appear
in the feature file.
Glyph classes from feaLib parser are tuples of strings, with an order and possibly containing duplicates.
However when building MarkGlyphSetsDef or MarkAttachClassDef we are only interested in the *set* of glyphs they contain, i.e. the unordered collection of unique glyph names.
Also, note how in the tests for otlLib.builder.buildMarkGlyphSetsDef, the input is given as set literals, not tuples:
https://github.com/fonttools/fonttools/blob/78ad48e/Tests/otlLib/builder_test.py#L633
* TupleVariationTest.test_compileDeltaValues(): also test floats
* TupleVariation: round deltas before encoding
Python 3 was raising 'struct.error: required argument is not an integer' and Python 2 was truncating when deltas are floats
Otherwise I get this error on python2.7:
SyntaxError: Non-ASCII character '\xc2' in file perimeterPen.py on line 87, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
If a zero value appears in a SinglePos statement, feaLib continues to
produce ValueRecords of format 0. But if a zero value appears in a
PairPos statement inside a horizontal compilation context, feaLib now
produces ValueRecords of format 4. Likewise, if a zero value appears
in a PairPos statement inside a vertical compilation context, feaLib
now produces ValueRecords of format 8.
The OpenType Feature Syntax specification is completely silent about this,
but the new behavior matches that of makeotf.
https://github.com/fonttools/fonttools/issues/633
`font.FDSelect[i]` returns a GID, not an index of `font.FDArray`.
Before this commit `.notdef` might have wrong glyph width in CharStrings,
if its fdSelectIndex is not 0 in the input font.
