path_remove_interior_points() doesn't seem to preserve direction

[nwoods-cimpress]

I'm guessing that this is not so much a bug, as much as "missing functionality", so bear with me.

I'm using flo_curves to manipulate paths in an application where whether paths are clockwise or counterclockwise is significant (specifically I'm manipulating overlapping glyph contours in OpenType), and path_remove_interior_points() seems to correctly handle overlapping lines correctly.

However, it doesn't seem to preserve the direction in the results. I've hacked together a unit test to illustrate:

#[test]
fn path_remove_interior_points_preserves_direction() {
    // This is a counter clockwise path roughly like a triangle, but with the addition of weird "prongs", roughly like this:
    //                 __
    //                 \/
    //                 /\
    //                /  \
    //               /    \
    //              /      \
    //           __/________\__
    //           \/          \/
    let triangle_with_prongs = BezierPathBuilder::<SimpleBezierPath>::start(Coord2(584.0, 46.0))
        .line_to(Coord2(327.0, 639.0))
        .line_to(Coord2(409.0, 628.0))
        .line_to(Coord2(147.0, 37.0))
        .line_to(Coord2(94.0, 93.0))
        .line_to(Coord2(634.0, 93.0))
        .line_to(Coord2(584.0, 46.0))
        .build();

    // This path is counter clockwise
    assert!(!triangle_with_prongs.is_clockwise());

    // We want to use path_remove_interior_points() to break this up into four triangles
    let split_triangles = path_remove_interior_points::<SimpleBezierPath, SimpleBezierPath>(
        &vec![triangle_with_prongs],
        0.01,
    );

    // And it succeeds - we have four triangles
    assert_eq!(4, split_triangles.len());

    // However, we also want to ensure that the directions are preserved in the split triangles.  Since we started with a counter clockwise
    // shape, we'd expect the "main" triangle in the results to be counter clockwise, and the "prong triangles" to be clockwise.  However
    // we're not getting those results
    assert_eq!(
        3,
        split_triangles.iter().filter(|x| x.is_clockwise()).count() // ERROR - seems to return '1'
    );
}

I realize that that working with shapes where clockwise and counterclockwise paths are interpreted differently is not something flo_curves does by default, and for the most part I was able to do the handling on my side, with this exception.

Thanks in advance!

[Logicalshift]

Yes: the algorithm converts all paths to clockwise paths before it performs any of the arithmetic operations, which simplifies the algorithm and also better deals with overlapping curves. The final result does try to follow the edges in this same direction if it can, but in your case this will produce paths whose direction depends on whichever edge was chosen first.

I think it actually isn't possible to do this in the general case because an output path can end up needing to be made of edges that originally came from two different paths, which could be moving in opposite directions.

It might be worth noting that the class that stores the intermediate result of the operation, GraphPath is publically available, and will contain the edges still in their original directions if you copy the algorithm from path_remove_interior_points(). I'm not sure how helpful this will be: you'll essentially need a new version of exterior_paths() in order to extract the set of paths you want here.