Subtracting shape from a bigger shape which entirely overlaps it doesn't seem to work

[andrewvarga]

I have an example where a larger ellipse entirely overlaps a smaller one. This is how it should look like:

Running that through flo_curves seems to produce this. Note that Subtract doesn't seem to subtract anything from the larger circle (Union and Intersect works well):

I'm getting similar results when using rectangles instead of ellipses.

Do you have a tip as to what could be a problem? I can send some SVG / path data if that helps.

Thanks!

[Logicalshift]

Ah, sorry for the delay in responding.

There's actually a circle subtraction test in the test suite (create_doughnut() and friends) so I think the algorithm should work. The output should contain both the inner and the outer path, so a will be a Vec of two paths (this is essentially what these tests look for). See https://github.com/Logicalshift/flo_curves/blob/a1c85645ece7c750c186f493075b912b27c14f07/tests/bezier/path/arithmetic_sub.rs#L48 for this test - just checking that two paths are returned should be enough to verify that the subtraction worked correctly.

Could the problem you're having be to do with the winding rule? flo_curves generates output intended for use with the even-odd winding rule, and since v0.7 always produces paths going in the same direction. I think it's quite common these days for graphics libraries to default to the non-zero winding rule, which will generate a filled circle in these circumstances.

[andrewvarga]

lo_curves generates output intended for use with the even-odd winding rule

Just wanted to get back to this, rendering the result with even-odd winding rule did resolve the problem indeed. I'm going to assume that flo_curves will always return data with the even-odd winding rule in the future for all of its operations, so I'll hardcode in our renderer (let me know if it should be queried instead, I missed any references to winding rule in the documentation).