otherwise, pytest test collection fails to import ufo_benchmark mode, as defcon/robofab are not specified as install requirements, thus may not be present when running the test suite.
The test suite is installed as a sub-package, so the test data must also be installed along with it.
The `__file__` attribute can be missing when importing a zipped package, so we load test files with `pkg_resources.resource_filename()`.
`random.randint`, which is used in `cu2qu.benchmark.generate_curve` function, yields
different results when run in Python 2.7 or 3, despite using the same `random.seed(1)`.
For this reason, the `test_results_unchanged` and `test_results_unchanged_multiple` tests
in `cu2qu_test` module fail when run under Python 2.
Backward compatibility was broken with Python 3.2 `random` module, as a side effect of
fixing a non-uniformity bug. For mor info see:
https://groups.google.com/forum/#!topic/comp.lang.python/KwALjKjF6Y4http://bugs.python.org/issue9025
To work around this, I dumped the result of generate_curve (running from Python 3.5.2 on
OSX) to a json file, and use that to run the tests.
I also stripped the white space to reduce the file size.
```python
import random
import json
from cu2qu.benchmark import generate_curve
random.seed(1)
curves = [generate_curve() for i in range(1000)]
with open("Lib/cu2qu/test/data/curves.json", "w") as fp:
fp.write(json.dumps(curves).replace(" ", ""))
```
fixup
otherwise, the direction would only flipped if the glyph contains at least one cubic curve; whereas, we want to reverse the contour direction of all the glyphs in the font, even if they are just made of straight lines.
Don't use zip(*fonts) as defcon fonts are dictionary-like objects and the ordering of the glyphs returned by __iter__ method is undefined.
Should fix#48
This was requested in https://github.com/googlei18n/cu2qu/issues/26
Plus:
- do not modify input glyphs unless they contain one cubic curve;
- make public functions return True/False to signal that the input
was modified or not (eg. no curves, or all quadratic)
For some reason, I was subtracting 1 from the spline lengths in the
test report. Not sure why that is, so I've assumed it was wrong (and
now we subtract 2 to get the length in number of segments).
Looks like changes like this don't have measurable performance
penalty, but they do help with analyzing profile output to see
which branch (n=1 or n!=1) takes more time.
...by calling split_cubic_into_three() twice. Gives another 5..9%
speedup. The thing is, while higher n values are lower-frequency,
the savings are also bigger. So the two offset out.
