No easy way of isolating multiple overlapping objects

[Andrzej]

After importing an emf or pdf file (at least these produced by MS tools), the drawing often contains a large number of overlapping (that is, placed on top of another) paths. Usually there are two to four objects objects describing every single element of the drawing.

Although there are methods for cycling the selection in z-order, it is very time consuming to clean up such drawings. Some semi-automatic way of removing "duplicates" would be very useful.

This might be a similar issue to the one discussed in Bug #521988. However, the proposed removeredundant.py extension does not work on the drawings imported from emf files (perhaps these overlapping objects are not *exact* duplicates?).

Also, because this issue significantly hinders porting drawings from MS tools to Inkscape, I'd argue that such function/extension should be shipped in a default installation of Inkscape.

[su_v (suv-lp)]

Tagging as 'boolops' for now - a command to open/remove redundant (aligned) edges of overlapping/coinciding objects (shapes, paths) would likely be added to the path operations listed in the 'Path' menu (a result could be a combined path reduced to non-redundant segments only).

[su_v (suv-lp)]

I'm not sure I correctly interpreted your request: the verb 'isolating' in your bug summary confuses me a bit. It does seem to refer to selecting a single object [1], not a new feature to remove redundant parts of stacked objects - could you clarify what 'to clean up such drawings' entails, and whether your issue is about selecting only, or about modifying/simplifying the content of opened/imported PDF (PS/EPS) documents?

Current trunk has a new feature easing the selection of stacked/overlapping objects (WIP):
<http://wiki.inkscape.org/wiki/index.php/Release_notes/0.49#Selector_tool>
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/35465/focus=35639>

[Andrzej (ndrwrdck)]

Suv, ultimately the goal is to remove all the redundant objects. In the description I tried to focus on the problem, not the solution.

As for the solution, an automatic tool would be great but I can imagine cases where it will not recognize some of the redundant objects correctly (imported drawings often include strange things when object filling, transparency or grouping was used). It might be necessary to step in and rework parts of drawing manually but currently that's rather painful process (cycling through the whole diagram using a Tab key).

The feature you linked to is fantastic! That alone (almost) solves this issue. The only (but rather important) change I'd make to it is to stop it jumping from the bottom to top or top to bottom of the stack after arriving at the last or first object because if cycling in z-order is needed, the objects are likely to be hard to distinguish.

[Andrzej (ndrwrdck)]

I just found a (rather obvious) method of cleaning such overlapping objects:

1. select all objects under cursor using Alt+drag (that's BTW a rather unfortunate shortcut, which is probably a reason why I've missed it in the first place).
2. Subtract the top-most object from selection by Shift+clicking on it.
3. Press delete.

That should leave only the top-most object.

I'm perfectly OK with using this method in my work, so we could even go ahead and close this bug. Still, I think there are some ideas to take from it (an automatic removal of redundant objects and cycling in the z-order).

[su_v (suv-lp)]

> to remove all the redundant objects

Objects only or redundant edges (Bug #521988) too? Both can affect selection… probably I got confused by the reference to that other report (which focuses on removing redundant edges of a combined path, as it can cause issues with certain output or print devices like cutters). AFAIU removing redundant edges (parts aka segments or sub-paths of objects) would be a quite different task then removing identical (or very similar) stacked objects.

[Andrzej (ndrwrdck)]

Objects only. I think I misunderstood the other bug report.

[su_v (suv-lp)]

>> Current trunk has a new feature easing the selection
>> of stacked/overlapping objects (WIP):
>> <http://wiki.inkscape.org/wiki/index.php/Release_notes/0.49#Selector_tool>
>> <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/35465/focus=35639>

> The feature you linked to is fantastic! That alone (almost) solves this
> issue. The only (but rather important) change I'd make to it is to stop
> it jumping from the bottom to top or top to bottom of the stack after
> arriving at the last or first object because if cycling in z-order is
> needed, the objects are likely to be hard to distinguish.

If you have access to recent development builds and can test the mentioned enhancement to the selection tool, please file new reports detailing your findings and proposals to improve the new feature - this would be helpful to polish it in time for the next stable release.

> 1. select all objects under cursor using Alt+drag (that's BTW a
> rather unfortunate shortcut, which is probably a reason why I've
> missed it in the first place).
> 2. Subtract the top-most object from selection by Shift+clicking on
> it.
> 3. Press delete.
>
> That should leave only the top-most object.
>
> I'm perfectly OK with using this method in my work, so we could even
> go ahead and close this bug. Still, I think there are some ideas to
> take from it (an automatic removal of redundant objects and cycling
> in the z-order).

IIRC 'Alt'+drag in the select tool context doesn't select _all_ crossed objects if they are precisely stacked on top of each other (it only gets the top most one) i.e. you could achieve the same affect by clicking once and deleting the thus selected top-most object. This (as well as your method) works well with two objects stacked on top of each other, but remains cumbersome if multiple objects are stacked on top (e.g. as you get when releasing the clip of many objects which have been clipped individually instead of as group, because the identical clip-path is inserted for each released clip).

[Andrzej (ndrwrdck)]

> IIRC 'Alt'+drag in the select tool context doesn't select _all_ crossed objects
> if they are precisely stacked on top of each other

Oh, my... it looks like you're right. Isn't it a bug in the selection mechanism then? When I press Alt I get the following message on my status bar:

"drag to move selected or *select by touch*"

This implies selecting all "touched" objects regardless of their position in the stack.

[su_v (suv-lp)]

> Isn't it a bug in the selection mechanism then?

Not necessarily - 'touch' doesn't have the same meaning as 'cross' (else it probably would have been called 'Cross select'). I do understand that it doesn't match your expectations, but haven't researched the original intent / discussion / implementation details to confirm it as "bug" in the selection tool.

From the manual:
 «Touch Select Multiple Objects: This will select all objects that the mouse cursor touches while being dragged. A red line will indicate the path the cursor took. This is very useful when needing to select multiple paths as found in engravings or hair. Holding the Shift down will prevent dragging an already selected object if the drag begins over that object»
<http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Select.html#Select-Mouse>

If 'touch' is interpreted as based on "visually" selecting objects on canvas, it would touch the top-most object from the stack, and not those hidden below - very much the same way a click selects the top-most object.

ISTM you are looking for several additional selection methods, and for some there might already exist feature requests/bug reports in the bug tracker. I'll search and provide some links to related reports tonight or later this week (re: reports about touch- and fence/cross-select).

[Andrzej (ndrwrdck)]

In the report of bug 818539 I've uploaded a sample imported emf and a resulting svg file. All the object, except for a bitmap, which is a subject of bug 818539, are imported in multiple "copies". In case of a rectangle separate object were generated for representing its outline and filling.