Improve robustness of curve fitting

[raphlinus]

This PR contains a number of improvements to the robustness and accuracy of curve fitting. A milestone is that seems to handle the test case of #268 fairly well. It also implements one aspect of #267 (handling the case where the quartic has no real roots), but does not implement the higher level driver proposed in that issue. Thus, it does its best to fit corners with smooth curves.

A list of the changes in somewhat more detail:

• The quartic solver simply reports when there are no real solutions, rather than panicking. A potential future expansion might be to compute complex coefficients, but that would require a dependency on complex math and does not seem to be needed here.
• The ITP solving for determining subdivision points chooses the conservative side of the bracket rather than the midpoint. This gives much better results when the function being solved has discontinuities. This also avoids problems with causing n to increase due to non-monotonicity of the curve fitting.
• The error metric for estimating the Fréchet distance between the source curve and the approximation has been revised substantially. Previously it was the ray projection method from Tiller and Hanson, but this can significantly underestimate error when the source curve has extreme variations of curvature. A particularly bad case (illustrated below) is when the source curve has a corner (or nearly so), in which case the cubic approximation might have a loop, and the error metric reports a low error because the loop is not sampled. Even so, the code is probably slower. There may be an error metric out there which is both faster than the current code and robust enough.
• The fit_to_bezpath_opt logic has been changed to make accuracy bounds tighter for the curve fitting steps; those are allowed to fail, and logic can deal with that. Previously it set a HUGE accuracy bound with the expectation that some solution would always be found. This should improve both robustness and performance (relative

The new method is based on arc length parametrized sampling of the approximation curve (the sample points are sampled evenly in parameter space in the source curve, which might possibly be improved, but otherwise would require solving inverse arc length problems there). While this error metric is more robust, avoiding the loops, it is also dramatically slower. Thus, this PR applies a hybrid approach, first estimating whether the source curve is "spicy" by determining whether the tangent of the delta between tangent vectors between samples exceeds 0.1 (the SPICY_THRESH constant in the code). If so, the arc length method is used (after first running the ray cast method).

Experimentation is encouraged, as the goal is truly robust curve fitting. The techniques deserve a proper writeup. One thing of note is that arc length is computed (as an integral) as another application of the ParamCurveFit trait; no changes were needed to the trait itself. It's also worth noting that errors in computing arc length make the error metric more conservative, so extreme care is not needed there.

[richard-uk1]

I have a test case. The code below can be copy-pasted into src/offset.rs. I tested on HEAD of robust_fit and got a hang, I think during the cubic solver.

#[cfg(test)]
mod tests {
    use super::CubicOffset;
    use crate::{fit_to_bezpath_opt, CubicBez, PathEl};

    // This test tries combinations of parameters that have caused problems in the past.
    #[test]
    fn pathological_curves() {
        let curve = CubicBez {
            p0: (-1236.3746269978635, 152.17981429574826).into(),
            p1: (-1175.18662093517, 108.04721798590596).into(),
            p2: (-1152.142883879584, 105.76260301083356).into(),
            p3: (-1151.842639804639, 105.73040758939104).into(),
        };
        let offset = 3603.7267536453924;
        let accuracy = 0.1;
        let offset_path = CubicOffset::new(curve, offset);
        let path = fit_to_bezpath_opt(&offset_path, accuracy);
        assert!(matches!(path.iter().next(), Some(PathEl::MoveTo(_))));
    }
}

[richard-uk1]

This looks awesome, I didn't realise that you also implemented a simplifier over BezPaths as well as improving the robustness of the original algorithm.

I didn't understand everything in the method, so I'm taking an 'empirical' approach to review - I've used the code in this branch and thrown some wierd curves at it, and it performs better than what's in master in all cases.