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.
This meant going back on my horizontal whitespace around operators
stance, but in this case I think it looks better to reduce whitespace
than to break up the line.
In some cases these changes were made for clarity, in some cases more
just for consistency. Anyways we should now have mostly consistent and
reasonably clear variable names everywhere.
