For the Tests/ folder, the next time we add a new type of files, we simply need to add a new glob pattern.
The source distribution is now in sync with the content of the repository as returned by `git ls-files`
When the tests are run with `python setup.py test` (e.g. from the ./run-tests.sh
script), we can't have setuptools install pre-compiled wheels for extra test
requirements (e.g. Brotli, unicodedata2).
Instead of failing, it's better that we skip the tests that have such extra
requirements.
NOTE: The recommended way to run the full test suite is by using tox
(like we do on the CI), or by installing pytest and the rests of requirements.txt,
and then run `pytest` command directly.
Note that we only use requirements.txt for running the test suite inside tox.
I didn't add (yet?) unicodedata2 module to 'install_requires' in setup.py.
Python 3.6 does not need it, as it's built-in unicodedata module is the
same as unicodedata2 backport.
PyPy is also excluded because currently there is no pre-compiled wheel
available for that implementation.
These originated from TTFs that were built from the test UFO masters using fontmake v1.2.0 with the command `fontmake -m BuildTest.designspace -o variable`
- remove unused import
- use snake_case instead of camelCase
- add two empty lines between module-level definitions
- rename 'elt' variable to 'element'
- don't make extra dict copy in _load_axis
According to https://github.com/LettError/designSpaceDocument
> Not all values might be required by all applications.
So if any of 'elements', 'sources' or 'instances' is missing, the dictionary
returned by designspace.load will not contain those keys.
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
