Path Count Restriction in Division, Cut and Difference
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
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
On Sun, 2016-01-03 at 01:31 +0100, Maren Hachmann wrote:
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.
If you've got an idea, it'd be great to see it step by step with the results at each step as each selected object is considered. Does this make sense?
Martin,
Am 03.01.2016 um 02:28 schrieb Martin Owens:
On Sun, 2016-01-03 at 01:31 +0100, Maren Hachmann wrote:
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.
If you've got an idea, it'd be great to see it step by step with the results at each step as each selected object is considered. Does this make sense?
Find it here: https://inkscape.org/gallery/item/7221/
Basically, it's duplicating the topmost object and repeating the operation for each selected object below. The combining part could be done by the user, if they choose to do so - but again, I think doing it this way is a little inconsistent - yet enomously useful... The extension is rather slow (because it reads through the whole document to find out about the stacking order *and* also launches a new Inkscape instance).
Maren
Martin,
On Sun, 2016-01-03 at 03:06 +0100, Maren Hachmann wrote:
Find it here: https://inkscape.org/gallery/item/7221/
Basically, it's duplicating the topmost object and repeating the operation for each selected object below. The combining part could be done by the user, if they choose to do so
but again, I think doing it this way is a little inconsistent - yet enomously useful... The extension is rather slow (because it reads through the whole document to find out about the stacking order *and* also launches a new Inkscape instance).
The code that does these actions is rather a mess. It /mostly/ always generates one shape and deletes all the rest. But of course cut and slice do a mass of different things (and sometimes the same things).
So to generate the right output we'd actually have to call it multiple times while not deleting the source and then deleting it in the end. Or changing the messy logic to something that can output multiple shapes.
I'll dabble with it for a while and see if I can make it into something.
Martin,
On Sun, 2016-01-03 at 02:12 -0500, Martin Owens wrote:
On Sun, 2016-01-03 at 03:06 +0100, Maren Hachmann wrote:
Find it here: https://inkscape.org/gallery/item/7221/
Basically, it's duplicating the topmost object and repeating the operation for each selected object below. The combining part could be done by the user, if they choose to do so
but again, I think doing it this way is a little inconsistent - yet enomously useful... The extension is rather slow (because it reads through the whole document to find out about the stacking order *and* also launches a new Inkscape instance).
The code that does these actions is rather a mess. It /mostly/ always generates one shape and deletes all the rest. But of course cut and slice do a mass of different things (and sometimes the same things).
So to generate the right output we'd actually have to call it multiple times while not deleting the source and then deleting it in the end. Or changing the messy logic to something that can output multiple shapes.
I'll dabble with it for a while and see if I can make it into something.
BTW, we should probably be moving our code to use lib2geom path operations.
Tav
Martin,
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
BTW, we should probably be moving our code to use lib2geom path operations.
You know what they say, if you can't code it, draw it. Here's the current function drawn out into a diagram:
https://inkscape.org/en/gallery/item/7226/
I didn't note the French comments that seem to turn into English half way through. But the structure and variables are there and you can get a sense for what's happening. (The Division code really is called `a bastard boolean operation` btw)
Here's hoping that drawing is a waste of time and Tav knows the 5 lines of code to replace it all! :-D
Best Regards, Martin Owens
On Sun, 2016-01-03 at 04:39 -0500, Martin Owens wrote:
BTW, we should probably be moving our code to use lib2geom path operations.
You know what they say, if you can't code it, draw it. Here's the current function drawn out into a diagram:
https://inkscape.org/en/gallery/item/7226/
I didn't note the French comments that seem to turn into English half way through. But the structure and variables are there and you can get a sense for what's happening. (The Division code really is called `a bastard boolean operation` btw)
I believe the original author used French and that the English comments were added by later developers.
Here's hoping that drawing is a waste of time and Tav knows the 5 lines of code to replace it all! :-D
It will not be five lines of code but it could be done a lot cleaner. Here is a rough outline.
* Verify input paths. * Find top path, convert to proper 2geom path (if path effect, etc.) * Loop over other paths ** Store style info ** Convert to proper 2geom path ** Boolean op with top path (top path not destroyed; if union, union becomes top path) ** If not union, save new path(s) if needed with style info. ** Delete old path * End loop * If union, save top path, else delete.
Tav
Best Regards, Martin Owens
On Sun, 2016-01-03 at 03:06 +0100, Maren Hachmann wrote:
Am 03.01.2016 um 02:28 schrieb Martin Owens:
On Sun, 2016-01-03 at 01:31 +0100, Maren Hachmann wrote:
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.
If you've got an idea, it'd be great to see it step by step with the results at each step as each selected object is considered. Does this make sense?
Find it here: https://inkscape.org/gallery/item/7221/
Basically, it's duplicating the topmost object and repeating the operation for each selected object below. The combining part could be done by the user, if they choose to do so
This is the behavior I would expect.
Tav
but again, I think doing it this way is a little inconsistent - yet enomously useful... The extension is rather slow (because it reads through the whole document to find out about the stacking order *and* also launches a new Inkscape instance).
Maren
Martin,
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Hi Martin, I can make a use case, but not right away. Maybe in the next couple of days? In general, if it avoids having to Combine many objects, to do e.g. a Difference all at once, it's a good thing!
brynn
-------------------------------------------------- From: "Martin Owens" <doctormo@...400...> Sent: Saturday, January 02, 2016 5:03 PM To: "Inkscape Devel List" inkscape-devel@lists.sourceforge.net Subject: [Inkscape-devel] Path Count Restriction in Division,Cut and Difference
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
On 2016-01-03 01:03 (+0100), Martin Owens wrote:
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.
Just a reminder - there is an existing merge proprosal which implements a recursive path difference operation (AFAIU the proposed feature in the branch to "remove overlaps" would do exactly what was discussed in the mentioned forum topic (a recurring request btw)):
https://code.launchpad.net/~inkscape+alexander/inkscape/flatten/+merge/26079...
participants (5)
-
Brynn -
Maren Hachmann -
Martin Owens -
su_v -
Tavmjong Bah