Apparently string slices are not as smart as I was hoping for.
Slicing a looong (say, 1MB) string and holding onto it is not a
good idea if done thousands of times. So, do fewer slicings and
decompile subtables immediately instead of holding onto data.
This makes me want to rethink the kind of data structures we use
for lazy processing.
Fixes https://github.com/behdad/fonttools/issues/317
It doesn't seem to be a good idea to round some points in a glyph but
not others. With this change, control points (which don't change)
that were equivalent to other non-curve points before conversion will
remain so. This can be significant when drawing with pen objects.
The rounding has been there since the initial commit; it's not clear
that it serves a purpose.
In the long term, we might want to make a different low-level API
for building ChainContextPos lookups; for now, this should fix the
current bug with SequenceIndex.
Resolves https://github.com/behdad/fonttools/issues/517.
There should be no semantic difference from this change,
since dependent lookups (the chain targets) are never directly
invoked by a feature. But the output of feaLib becomes more
similar to the output of makeotf, which helps debugging.
Before this change, we had only emitted a SinglePos (GPOS type 1) lookup
for a statement like `pos A' B' 20`; after this change, we always emit a
chain rule even if there is no context. There is a semantic difference if
the rule is preceded by a `ignore pos` statement. Omitting context-free
contextual chains was actually not a (premature) optimization, but an
artifact that came from the representation of glyph patterns.
https://github.com/behdad/fonttools/issues/516
After this change, feaLib generates the exact same output as makeotf
for the test case in `bug453.fea`. Before this change, feaLib had
rejected the input as malformed.
Our new behavior is in blatant violation of the OpenType Feature File
Syntax specification, which writes: "NOTE! If a GDEF table is not
explicitly defined in the feature file, [...] all mark glyph classes
must be disjoint". However:
1. makeotf does not enforce this constraint;
2. existing feature files happily define non-disjoint markClasses;
3. existing tools such as the Glyphs font editor generate feature files
with non-disjoint markClasses;
4. it is not obvious what the intention of this constraint would be.
Therefore, fewLib now follows the makeotf implementation, intentionally
ignoring what is mandated by the specification. I've proposed a spec change
at https://github.com/adobe-type-tools/afdko/issues/106.
Resolves https://github.com/behdad/fonttools/issues/453.
The glob pattern determines which classes are considered for test collection by pytest.
We already follow this pattern for the unittest.TestCase derived subclasses
(which are collected regardless of this option).
Apparently I need to do that, or the child python process does not see fontTools in the path.
Another workaround woud be to ensure that fontTools is installed, at least in editable or develop mode (via `pip install -e .`). But the way we temporarily extend the PYTHONPATH in run-test.sh is less intrusive.
It seems like Appveyor no longer needs the batch script to configure the MSVC compiler variables.
Also, since appveyor already comes with all the python versions we need, we don't need the install.ps1 script any more.
Brotli is now installed by tox from requirements.txt inside the test virtualenv.
This way test discovery will work not only with the current unittest and doctest modules, but also with pytest's own kind of tests.
When run with no argument, the shell script will call the py.test command, which will scan the whole Lib/fontTools directory for all relevant tests.
If args are provided, tests are filtered if any of the substrings specified
match. The filtering works not only on the modules' file names (as the previous grep approach), but also on the names of the test functions, classes and methods. Pretty cool, huh?
We can still specify whether to run pytest with python -2 or -3 (provided pytest is installed on both Python versions).
And we don't need to print the python version any more as pytest does it for us.
Finally, there's no need to export PYTHONPATH -- pytest takes care of that too!
the glob pattern will restricts the search only for pytest's kind of tests; it has no effect on methods of unittest.TestCase derived class, since pytest still uses unittest's own collection framework to collect those.
The 'minversion' is required to support some of the latest advanced features.
The current py.test is 2.8.7. You can update it with `pip install --upgrade pytest`.
