The file contains outdated information and nobody is maintaining it any longer.
Plus it only works on Linux, and only if pip installing as sudo (which is bad!).
We need proper Sphinx+ReadTheDocs kind of documentation.
To run tox on specific versions of python, you can use the -e option:
$ tox -e py27
$ tox -e py35
To only run tests which match the given substring expression, use
py.test -k option. Do `py.test -h` for more info.
When running `tox` command without specifying any `-e` option, or when no $TOXENV environment variable is specified, the 'envlist' in tox.ini file determines the list of environment tox will operate on.
http://tox.readthedocs.io/en/latest/config.html#confval-envlist=CSV
I chose Python 2.7 and 3.5 because I assume they are the versions that other fonttols developers run their tests on locally, before pushing and let the CI run the tests on the rest of the pythons.
In the upstream google/brotli, if the `decompress` function receives an empty byte
string, it returns a brotli.error; whereas in 'brotlipy' it does not raise but
returns an empty string b"":
https://github.com/python-hyper/brotlipy/issues/43#issuecomment-240378257
This test case asserts that when 'totalCompressedSize' in the WOFF2 header is
incorrectly set, the woff2 reader fails -- either because the brotli decoder
raises an exception, or it returns a string whose length is not the one expected.
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)
Fixes https://github.com/behdad/fonttools/issues/314
Previously the warning message was wrong (probably a regression)
as it was reporting the the length of all kern data as "excess".
Fixing that, I see 4 bytes excess in Calibri. Up to 4 is alright,
since many compilers add padding and wrongly add 4 instead of 0
sometimes.
this should speed up the Travis and Appveyor builds, as we don't need to compile
Brotli from source, at least on OSX and Windows. Linux will still use the
.tag.gz source distribution.
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.
