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

Bug #1005085 reported by kreaninw
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Low
Alvin Penner

Bug Description

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.

Revision history for this message
kreaninw (kreaninw-ultimate) wrote :
Revision history for this message
su_v (suv-lp) wrote :

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)

tags: added: clipping regression selection
removed: clip operation
Changed in inkscape:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
jazzynico (jazzynico) wrote :

Reproduced on Windows XP, Inkscape trunk revision 11655.

Changed in inkscape:
status: Confirmed → Triaged
su_v (suv-lp)
Changed in inkscape:
milestone: none → 0.49
Revision history for this message
ivan louette (ivan-louette) wrote :

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

Revision history for this message
su_v (suv-lp) wrote :

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).

ScislaC (scislac)
tags: added: blocker
Revision history for this message
Alvin Penner (apenner) wrote :

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.

Revision history for this message
Alvin Penner (apenner) wrote :

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.

Revision history for this message
su_v (suv-lp) wrote :

> 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.

Revision history for this message
su_v (suv-lp) wrote :

> 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.

Revision history for this message
Alvin Penner (apenner) wrote :

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.

Revision history for this message
Alvin Penner (apenner) wrote :

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

Revision history for this message
su_v (suv-lp) wrote :

> 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).

Revision history for this message
Alvin Penner (apenner) wrote :

yes, sorry about that, reverting this in rev 11946

Revision history for this message
Alvin Penner (apenner) wrote :

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...

Revision history for this message
Alvin Penner (apenner) wrote :

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

Changed in inkscape:
status: Triaged → Fix Committed
su_v (suv-lp)
Changed in inkscape:
assignee: nobody → Alvin Penner (apenner)
tags: removed: blocker
Revision history for this message
Liam P. White (liampwhite) wrote :

bump for bug #1322940

Bryce Harrington (bryce)
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.