Switch to evenodd rule for SVGs?

[bluenote10]

I noticed that currently the SVGs don't specify a fill-rule, which means that they default to a nonzero fill rule (i.e., winding order matters). Some thoughts:

• I'm not sure if Martinez implementations actually care about winding order. They most likely ignore it at the input and input is rather interpreted in "evenodd" semantics. As for the output I haven't put any effort (or tests) into rust-geo-booleanop to guarantee correct winding order; all tests seem to assume evenodd semantics. So in general you may see better results using evenodd semantics.
• It looks like the input data itself does not follow the nonzero winding rule properly. How have the pngs of foo and twointersectingcontours been generated? It seems using "evenodd" fill rule is necessary to obtain them. This inconsistency leads to some wrong results: For instance, rust-geo-booleanop has an optimization when performing a union operation with an empty polygon: It returns the other polygon as is. Currently this shows a wrong result, because the input polygon gets converted wrongly.

Depending on what you want to achieve (testing for correctness w.r.t. evenodd or nonzero rules) you may either fix the input polygons or change the SVG conversion to evenodd. This can be done by changing line 9 of svg.js to:

w('<path style="fill:#000000" fill-rule="evenodd" d="')

This fixes a lot of "false negatives" for me as shown here: https://github.com/21re/rust-geo-booleanop/pull/15

[daef]

Thank you very much for this catch, my gut told me that I've forgot something along those lines..:

As you can see I already have evenodd for the unisample svgs but I forgot to update the duplicated versions of svg.js, will fix that tomorrow I hope :)

[daef]

I use evenodd now everywhere and I've added your feature branch since it's so easy :)

[bluenote10]

I use evenodd now everywhere and I've added your feature branch since it's so easy :)

Cool thanks!