Clipping path not set clipped object to its new size immediately.

[kreaninw]

1. Selected 2 objects, one above and one below each other.

2. In menu Object > Clip > Set, which use to make clip operation. Clipping path will not set clipped object to its new size immediately unless user moved the clipped object.

Clipped object should not remain in its original size after clip operation. Because user doesn't intend to use a whole object anymore. Unlike mask which user can play with transparency and use that object as a whole.

This problem is not reproduce in Inkscape on Ubuntu Software Center.

I'm using the latest version of Inkscape Trunk with Ubuntu 12.04 LTS 64-bit, updated to the latest version.

[su_v (suv-lp)]

Known regression in current trunk due to caching of visual bounding box values.

Related reports:
bug #970370 Zoom to entire drawing doesn't work correctly (cached visual bbox info)
bug #960986 Visual bounding box not updated when changing filter settings
bug #955141 Converting clipped object to pattern produces rasterised pattern (see comment #5-6)

[jazzynico (jazzynico)]

Reproduced on Windows XP, Inkscape trunk revision 11655.

[ivan louette (ivan-louette)]

Reproduced on Kubuntu 12.04 32 and 64 bits, Inkscape rev 11761. and 0.48.3.1 r9886

[su_v (suv-lp)]

ivan louette wrote on 2012-10-28:
> Reproduced on Kubuntu 12.04 32 and 64 bits, Inkscape rev 11761.
> and 0.48.3.1 r9886

Note: this regression (bug #1005085) only affects trunk (>= r10618), but not stable (0.48.x).

[Alvin Penner (apenner)]

fwiw, if you go into Preferences and set the preference to be Geometric Bounding Box, then the problem appears to be even more serious. Not only do you retain the original large bbox, but the large bbox persists even after using the arrow keys to do a drag.

[Alvin Penner (apenner)]

a partial fix has been committed to rev 11944. I believe this fixes the original report. However, two side issues remain, perhaps not quite as common to encounter:

1. From Bug 1067271, load the file 'clip-path.svg'. After you set the clip, the bbox will disappear entirely (previously it was too large). You can recover the bbox by touching one of the arrow keys to force a refresh. This appears to be related to the fact that this is a nested clip.

2. in Preferences, set the bbox to be geometric Bounding Box. Then when you set the clip, the bbox will be too large and will not change its size even when using the arrow keys to drag.

[su_v (suv-lp)]

> 2. in Preferences, set the bbox to be geometric Bounding Box. Then when
> you set the clip, the bbox will be too large and will not change its
> size even when using the arrow keys to drag.

This is intentional (AFAIU - at least it has been like this ever since I know Inkscape (0.46)): the geometric bounding box of clipped objects includes the clip-path, the visual bounding box otoh is supposed to have the size of the visual (clipped) part only.

[su_v (suv-lp)]

> the geometric bounding box of clipped objects includes the clip-path

Sorry - correction: the geometric bounding box «returns the object bounding box as defined by SVG (does not consider stroke, filters, clipping paths, masks, etc.).» - i.e. it has the size of the unclipped object.

[Alvin Penner (apenner)]

cool. In that case the only remaining issue that I know of has to do with nested clips, where the problem seems to be one of figuring out "which" object to refresh.

[Alvin Penner (apenner)]

sorry, I responded to the wrong message, time to call it a day...

[su_v (suv-lp)]

> 1. From Bug 1067271, load the file 'clip-path.svg'. After you set the
> clip, the bbox will disappear entirely (previously it was too large).
> You can recover the bbox by touching one of the arrow keys to force a
> refresh. This appears to be related to the fact that this is a nested
> clip.

I also see this with r11944 (default prefs) when creating a new clip in a new document without nested clips - e.g. when clipping with an ellipse/circle (as opposed to a path or rect) or with a group containing a single rectangle. If it happens, there no visual clue at all that the just clipped object is still selected (except the message in the status bar).

[Alvin Penner (apenner)]

yes, sorry about that, reverting this in rev 11946

[Alvin Penner (apenner)]

a second attempt to fix this has been committed to rev 12005. This will affect only the visual bbox. It appears to work well for the cases I have seen so far, including groups; however, further testing would be welcome...

[Alvin Penner (apenner)]

since the geometric bbox behaviour is a pre-existing behaviour, which is separate from this bug report, I'm going to mark this as fix committed

[Liam P. White (liampwhite)]

bump for bug #1322940