Avoid merging intersecting paths

[jzbrooks]

Merging paths that overlap can cause problems with transparency determinations related to fill rules and can negatively impact paths which make use of relative coordinates.

Avoiding merging those paths addresses the issues in #59 also, but in a more robust way—so we can consider merging even odd fill rule paths, so long as they don't intersect.

This intersection test is fairly corse. An axis-aligned bounding box is computed for each path and a simple rectangle intersection test is performed. Since paths aren't typically rectangular, sometimes nearby but non-overlapping paths will be considered intersecting. There are more involved algorithms that can improve on this mentioned in #88, but:

a) the bounding box check is fairly good and the benefits of merging even odd paths outweigh the losses w.r.t. occasionally not merging two paths that don't overlap

b) the downside is a slightly larger than optimal graphic, but not an incorrect graphic, so improvements regarding intersection precision should only really shrink the graphic—not change its semantics.

Fixes #88, Fixes #101

[jzbrooks]

I used https://codepen.io/branneman/pen/nBjeLo to sketch the bounding boxes to visually verify.

(some of these screenshots were taken before I doubled the interpolation resolution)

absolute elliptical arc

absolute polyquadratic

absolute smooth polyquadratic

rotated elliptical arc (toggling sweep flag)

The elliptical arc's box is computed for the whole ellipse, which you can see in the recording by me flipping the sweep flag. Not totally ideal, but good enough for now. The downside is similar to the bounding box approach in general—at worst we avoid merging paths that really could be merged but the image is not warped. Interpolating the ellipse with endpoint parameterization is kinda tricky.

arc-flip-bounding-box.mov

heart

Minnesota (regression 60)

smooth quadratic

relative polyquadratic

relative smooth polyquadratic

standalone smooth curve