I'd have had use cases for doing it this way:
Every object is treated separately (the uppermost object being applied to each selected object below). This would often have saved a lot of repetitive work for me, especially for 'difference' (which would then *almost* work like an inverted 'crop') - at least before I found out about the extension.
But I guess this would be inconsistent with how the other, already existing, multi-path operations work?
I'm not sure I've even figured out how your way works, Martin... I think I wouldn't be able to easily imagine the result I'll get from them. Would definitely need documentation ;)
Maren
Am 03.01.2016 um 01:03 schrieb Martin Owens:
I've committed a change to splivarot.cpp to remove the restriction which stopped our difference/cut/division functions from working on multiple paths.
I was reading the forum post at http://www.inkscapeforum.com/viewtopic.php?f=5&t=20762
and it didn't seem to make much sense, so I did a few tests which I've posted here: https://inkscape.org/en/gallery/item/7216/
You can see we do the most sensible things already and the new functionality enabled by the commit doesn't seem to make a /lot/ of sense as far as I can see, but then I'd like to not artificially restrict the function because someone might find it interesting.
The other hand is that there might be a more common sense way of doing the functions. Maybe by making a union first, or some other thing. But we'd first have to see examples on what users think they'll get when they run these operations on their multiple paths.
Best Regards, Martin Owens
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel