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
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.
I guess this was done for consistency with names in FontTools, but I
gotta say it was bugging me that some functions in this module used
underscores and some used camelcase. Style guide says underscores.
This is very subjective, but my preference is more whitespace.
Generally the only place I didn't put in whitespace was for
multiplication within statements that also contained additions,
without parentheses.
This reverts commit 79beda96a4e26d5d1778f24de673cf14c6bda1ac.
Apparently now Travis expects what my local machine expects. I swear,
Travis is messing with me....
