@cmyr noticed that sometimes with some degenerate cubic curves (e.g. those where control points are on the same line), cu2qu can produce different number of quadratic off-curves depending on whether it is running in compiled cython mode (as one would get when installing from the wheels that we publish to PyPI) vs pure-python mode (e.g. when pip installing fonttools in editable from a local git checkout inside a python environment that doesn't have cython, or without explicitly asking for FONTTOOLS_WITH_CYTHON=1 at built time).

I isolated one of these offending curves (from BilboPro.glyphs) to create the test.

The calc_intersect function calls dot to compute the vector dot product, in this situation this is expected to be 0.0 and trigger a ZeroDivisionError.

But for some reasons (implementation details of floating-point and complex math in CPython vs C/Cython) we don't get 0.0 in both modes, but something very close (about 2e-17) to 0.0 in one of the two, whereas the other one gives exactly 0.0. They are both correct within IEEE 754 floating-point precision, but only an exact 0.0 triggers the ZeroDivisionError.

To be safe and get consistent results in either case without relying on particular implementation details, we should just clamp to 0.0 when |result|<1e-15 and go home.