clip object selection glitch

This is a matter of preference, as many people don't want to select "phantom" objects which are not actually visible on-canvas.

ScislaC, if I understand what the original reporter is pointing out, the problem is that the phantom objects are getting in the way of selecting visible objects in the phantom object's path. I believe the original reporter is forced to select phantom objects because of this bug.

This issue really drives me crazy sometimes too. Let me try to explain it in more detail so it's clear what's going on:

1) Say I have a 1024x768 image and I want to use just one smaller element in it (let's say the smaller element is 200x200.) I create a 200x200 rectangle, and clip the 1024x768 image using it so now only the 200x200 clip of the larger image is visible.

2) If I then try to select a 100x100 object outside of the 200x200 clipping area AND within the non-visible area the 1024x768 image *would* be were it not clipped, it still selects that 200x200 clipping.

3) If I try to then revert to rubber-band selecting the 100x100 object of my desire, I need to scroll way out of the way of the invisible, 'phantom' 1024x768 object just to be able to get a clean swath of canvas from which to start dragging from to create my rubber band.

I believe the idea behavior is that if I have a 1024x768 object clipped by a 200x200 rectangle such that only the 200x200 rectangle's worth of the 1024x768 object is visible, then only the 200x200 visible area should be selectable. The area of the 1024x768 outside of that visible 200x200 clipping should not be selectable.

This is not matter of preferences. This is a bug, and a regression, because it worked properly before.
The bounding box is surround the clipped object, but clicking on the clipped-out area still selects the clipped object.
I'm attaching a screencast of the issue. Notice the placement of the pointer when I try to select the magenta rectangle.

gez,

Correct, it is not a matter of preference. I misunderstood the report before, and and have no idea how I got the intent so backwards. Definitely a regression.

The Alt-click workaround doesn't help if you need to rotate the object below the clipped object resp. the clipping path. You actually have to change the stack order to have access to the rotation handles of the lower object.

Well, today is 22/11/2009, Inkscape 0.47 is in the wild and this serious (and irritating) glitch is still there. Same here (see image attached)

Will this bug get fixed?

I don't want to urge ...
but perhaps in 3, 4 years ...
it would be pretty to see this bug fixed.

Isn't this a matter of 10 minutes if you know the code?

I investigated this issue a little and it seems that it actually did not work (even) in Inkscape 0.46.

In 0.46, you can select invisible (clipped/masked) objects as well. The difference is that you need to click inside bounding box of visible part of the clipped object, so if you try this just with rectangles, it seems it is working. However, if you try this with e.g. circles, you can select that invisible part of the clipped object (provided you click inside the bounding box).

In current version (to be precise r9020, but I think it is current enough), you can select invisible parts of clipped objects even outside of that "small" bounding box that was in effect in 0.46. Please note that you cannot select invisible objects outside of area of drawing (as when you select "Resize page to drawing or selection" in Document properties). So it appears handling of bounding boxes is at least inconsistent in whether invisible parts of masked objects should be selected or not.

So one may say that neither version behaves correctly.

The change in behavior described above was caused by revision 7451, in nr_arena_item.cpp, nr_arena_item_invoke_update function, particularly:
@@ -272,7 +278,8 @@
             item->state |= NR_ARENA_ITEM_STATE_INVALID;
             return item->state;
         }
- nr_rect_l_intersect (&item->bbox, &item->bbox, &item->clip->bbox);
+ // for clipping, we need geometric bbox
+ nr_rect_l_intersect (&item->drawbox, &item->drawbox, &item->clip->bbox);
     }
     /* Masking */
     if (item->mask) {
@@ -281,7 +288,14 @@
             item->state |= NR_ARENA_ITEM_STATE_INVALID;
             return item->state;
         }
- nr_rect_l_intersect (&item->bbox, &item->bbox, &item->mask->bbox);
+ // for masking, we need full drawbox of mask
+ nr_rect_l_intersect (&item->drawbox, &item->drawbox, &item->mask->drawbox);
+ }

I believe it is not good idea just to revert this change though, unless there is not a better option, as it would not solve the problem for non rectangular clip/mask and if I understood it correctly it fixed some rendering issues.

Also I have thought about what the correct behavior really is. For clip it is obvious, but what to do with ([semi]transparent/bitmap) masks?
One option would be to take the shape of mask when testing for hits. Other option would be to look whether the mask completely hides the masked object at the mouse location
(consider greyscale bitmap or gradient used as a mask...).
(Probably this could be configurable as well)

This image describes where clipped objects can be selected in Inkscape 0.46, current version and what is the expected behavior

In case there is no better solution, this patch brings back Inkscape 0.46 behavior as a workaround. Please note that this does NOT really fix this issue and works ONLY if you have rectangular clips/masks. See testcase description image attached to this bug report for details. IMHO, we should find a really working solution.

Maybe an option could be added into preferences to control this?

From inkscape-devel email on this bug:

> 1. What handles click events on the canvas
> 2. Where is the logic that decides what gets selected

The function that selects the object under the cursor is at
event-context.cpp:1079. Through some indirection it calls the
find_item_at_point at document.cpp:1197 and this in turn calls
nr_arena_item_invoke_pick at display/nr-arena-item.cpp:635 which calls
a GObject virtual function; for shapes it executes nr_arena_shape_pick
at display/nr-arena-shape.cpp:1078.

You need to insert the fix into find_item_at_point by also testing the
mask and clip, either using another call to nr_arena_shape_pick or
some other method. Note that while masks can be tested in the usual
way, for clippaths you need to treat them as filled and unstroked
regardless of their actual style. This requires adding an extra
parameter to the virtual functions.

Regards, Krzysztof

Possible workaround (as long as the bug is not fixed):
after applying the clip, wrap the clipped object in a group (Ctrl+G) - now the hit region is the visible region only (works for both clips and masks).
(tested with Inkscape 0.47, 0.48 and 0.48+devel r9834)

Please ignore my previous comment - apparently only worked in a few (lucky) test cases, but not in general.

mmm its actually really annoying.. i mean, when you use inkscape for the occasional card design, you hardly notice it. But when its used seriously for production work.. man it does get in the way *a lot*, as layers and objects get complex and piled up.
Hopefully itll get fixed in this 0.48 series..
thanx

I'm currently running inkscape-0.48.0-1.fc14.3.x86_64 (Inkscape 0.48.0 r9654) and I still see this bug. It is not as severe as before - the phantom image is smaller than the full original image before clipping - but it is still a bad, high-impact bug and it affects me on a near daily basis.

~suv, your workaround is what I've been using to cope with the program. Usually I'll group it with a small transparent square and it hasn't ever not worked for me before. It is an annoying background but the only way I've found to cope.

The bug is still there on 48.1 on windows and it is REALLY driving me nuts because with the way I have to use this program (panels for biological papers -> a lot of clipping) I constantly run into it. A fix would be really appreciated

Niedi, use suggested workaround: group the clipped object (CTRL+G), and the hit region will be the visible area.

That work-around only appears to work intermittently Inkscape 0.48.1 r9760 for me. I'll add a vote to the annoying call. This one's incredibly annoying for making website mockups, where you need lots of clipped sample images.

I also find this bug very annoying. Although I just tried the "Ctrl+G" trick and it seemed to work, this really has to be fixed.

Hi folks, I teach Inkscape and yet again ran into a 25 minute tangent trying to figure out why a student was running into inexplicably bizarre behavior in Inkscape. Turned out it was this clipping glitch!

If someone can fix this bug and get the fix upstream I'll send the person who fixes it a $100 Amazon gift card.

I am going to assume that the reason this bug doesn't get fixed is because it isn't really a bug. It works as intended and as advertised - Inkscape is an SVG editor and a Clip operation in SVG does not change the boundary size.

However there's one thing which must be fixed.

The rubber band should be around the boundary, not the clip.

The reason why the Clipping behaviour is being reported as a bug, and why all the related bugs have been reported, is because the user interface is __outright_lying__ to them about what they can do.

If the rubber band stayed at the size of the union of the objects then at least users would be able to see what they are dealing with, and maybe look for a way to resolve it, !!like grouping!!!

W-barath-hotmail wrote
> I am going to assume that the reason this
> bug doesn't get fixed is because it isn't really
> a bug. It works as intended and as advertised (…)

No - it is a confirmed regression (compared to 0.46) [1] and not the expected behavior. The issue isn't fixed yet because it is not trivial to fix (see earlier comments by Martin Sucha and Alex Leone).

> (…) a Clip operation in SVG does not change the boundary size. (…)

Any sources for this statement? AFAIU, clipping and masking are different concepts in SVG [2]. You want Inkscape to treat them identically and use the same (visual) bounding box ("rubber band"?) for clipped as well as masked objects? (Currently, the selection bounding box differs for clipping and masking: the (visual) bbox of a clipping is limited to the clip-path, whereas the (visual) bbox of masked objects is the same as without mask).

> and maybe look for a way to resolve it, !!like grouping!!!

Grouping doesn't change the size of the selection frame ((visual) bounding box): the size of the (visual) bounding box of a group is the same as the union of the (visual) bounding boxes of its members. Grouping happens to be useful as a workaround because apparently the regression is only triggered if there are other objects stacked below the clipped object within the same layer/group (or drawing level), see e.g. duplicate bug #395874).

[1] «you can select invisible parts of clipped objects even outside of that "small" bounding box that was in effect in 0.46.»
[2] «The clipping path restricts the region to which paint can be applied. Conceptually, any parts of the drawing that lie outside of the region bounded by the currently active clipping path are not drawn.» <http://www.w3.org/TR/SVG11/masking.html#ClippingPathsIntro>

Maybe I misunderstand what this means then:

"14.3.6 Clipping paths, geometry, and pointer events

A clipping path is conceptually equivalent to a custom viewport for the referencing element. Thus, it affects the rendering of an element, but not the element's inherent geometry. The bounding box of a clipped element (that is, an element which references a ‘clipPath’ element via a ‘clip-path’ property, or a child of the referencing element) must remain the same as if it were not clipped. "

In the browsers at least, it is interpreted to mean that although the area outside the intersection is not rendered, it still receives pointer events.

> Thus, it affects the rendering of an element, but not the element's inherent geometry

Maybe you want to use the geometric bbox mode in Inkscape (the one which shows the geometric boundaries, not the visual ones): the geometric bbox of a clipped object is as described in your quote. The visual bbox on the other hand includes the visual i.e. clipped part only.

But maybe it's me misunderstanding the spec.

The bug itself drives me crazy, but only because the user interface is inconsistent. If the rubber band consistently showed the selection area of the object, then when I clicked the 1000-px square which is clipped to 100px at the opposite side of the screen, I would then be able to say to myself, "Oh, silly me, there's a huge clip object in the way." instead of "What the $#@! is going on? I didn't click even remotely close to the object which just got selected and not even within half a screen of its bounds?!" - which is what everyone is complaining about. The inconsistency of the user interface.

This bug is fixed in my GSoC branch, which will probably make it into 0.49. I will also backport the fix to 0.48 stable.

Fixed in 0.48 stable branch in revision 9823.

Note that the upcoming 0.48.2 release will not contain the fix. It will be present in 0.48.3, which should appear before the 0.49 release.

Now also fixed in trunk, r10579

Works great!

Thanks for fixing this.

Works perfectly for me on Kubuntu 11.04 !

Thanks a lot !!!

ivan

Krzysztof, I'm going to try to build it so I can test it on Fedora, and once I verify it's fixed I would be happy to send you a $100 Amazon gift card. Let me know what email address you'd like it sent to.

Sounds like the it is fixed in an unreleased update? Great! This bug really gets in the way of the kind of raster editing I like to do; this project took a lot of alt-clicking:

http://daghead.blogspot.com/2011/05/trojan-fader-style-diced.html

Can someone please help me get a hold of the 0.48.3 installer? This German site for the Windows version is not helpful.

@Daghead - 0.48.3 has not been released yet (hence no installers are available). Please note also that the status of this report is 'Fix Committed' and not 'Fix Released'.

When Inkscape 0.48.3 is released, it will announced on Inkscape.org, and the bug status will get changed to 'Fix Released' (in case you are monitoring this report).

finally... after 2 years.
hope to see it working in 0.48.3

for now only the grouping workaround saves me.

mairin: my e-mail address is: <email address hidden>