trunk: clip-path of clipped group incorrectly scaled when changing default units (rev >= 12554)

Bug #1287288 reported by su_v
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Medium
Alvin Penner

Bug Description

Steps to reproduce:
1) launch trunk with default (new) prefs
2) open attached document
3) switch to outline view mode (to see the clip-path)
4) change default units to 'mm'

Expected result:
The visual content of the document is unchanged when changing the default units.

Actual result:
Clip-path and clipped group scale differently after the unit change, and the visible area of the clipped group is different than before.

Notes:
- Equally affects masked groups.
- Does not happen if the clip is applied to the object itself.

Based on tests with archived builds on OS X 10.7.5
- not reproduced with rev <= 12552
- reproduced with rev >= 12554
the regression seems to have been introduced with the merge of the GSoC units branch in revision 12554
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/12554>

Revision history for this message
su_v (suv-lp) wrote :
summary: trunk: clip-path of clipped group incorrectly scaled when changing
- default units
+ default units (rev >= 12554)
Revision history for this message
su_v (suv-lp) wrote :

Sample file with masked instead of clipped groups.

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

confirmed on Inkscape rev 13107

Changed in inkscape:
status: New → Confirmed
su_v (suv-lp)
Changed in inkscape:
importance: Undecided → Medium
Revision history for this message
su_v (suv-lp) wrote :

Reproduced with r13493 (inkscape-trunk PPA) on Ubuntu 14.04 (VM, 64bit; host: OS X 10.7.5).

Changed in inkscape:
status: Confirmed → Triaged
ScislaC (scislac)
tags: added: blocker
Revision history for this message
su_v (suv-lp) wrote :

Seems to be fix by mathog's changes in r13544:
<http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13544>
 (reproduced with r13543, not reproduced with r13545 using the two test cases attached to the report)

Can others confirm, or are possibly aware of test cases not yet fixed? See also:
<http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/44323>

Revision history for this message
David Mathog (mathog) wrote :

r13549 removes this fix but leaves it intact for #1287288. For discussion of why I had to take it back out see <http://thread.gmane.org/gmane.comp.graphics.inkscape.devel/44323>

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

fix committed to rev 13561

the necessary transform is applied directly to the clip or mask in the defs section

Changed in inkscape:
status: Triaged → Fix Committed
Revision history for this message
Tavmjong Bah (tavmjong-free) wrote :

I'm not sure that this is a correct fix. If two items refer to the same clippath won't the transform be done twice? Also, what if an item is both clipped and masked?

I've started looking into a similar problem with <use> that points to a <symbol> inside a <defs> section..

su_v (suv-lp)
Changed in inkscape:
assignee: nobody → Alvin Penner (apenner)
Revision history for this message
Alvin Penner (apenner) wrote :

>> If two items refer to the same clippath won't the transform be done twice? Also, what if an item is both clipped and masked?

good questions. with respect to the first question I don't know what would happen. I have not been able to produce an example that illustrates that point.

wrt the second question, attached is a file that illustrates the problem. The example fails after the unit change. However I think the fix for this should be relatively simple, and I will investigate it tonight. If there is no objection, I will commit a proposed solution today or tomorrow, if I find one.

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

improved version committed to rev 13562, to allow for the case where a group contains both a clip and a mask

ScislaC (scislac)
tags: removed: blocker
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.