interaction between rx and ry when resizing ellipse (or rectangle)

Bug #1254822 reported by Alvin Penner
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Invalid
Undecided
Unassigned

Bug Description

- Windows XP, Inkscape rev 12792
- use gui to draw ellipse
- load the XML editor so you can see live display of both rx and ry for ellipse

1. choose F1 and vertically resize the ellipse by dragging to increase ry
- note that rx decreases very slightly.
- the effect is quite small. For example if the original rx = 100 and ry = 150, then increasing ry to 280 will decrease rx to 99.77. Decreasing ry back to 120 will increase rx to 100.06 or so.

2. the same effect can be seen when resizing a rectangle. Large increase in height will result in small change in width.

3. the effect disappears if you uncheck the option in Preferences that says "Scale Stroke Width"

4. the effect also disappears if you use the XML editor, not the gui, to change the ry value of the ellipse, or the height of the rectangle.

5. not reproduced in Inkscape 0.48.4. (possibly becuase in 0.48.4 the parameters rx and ry are not directly modified by a drag operation, instead the transform element is modified)

su_v (suv-lp)
tags: added: precision shape-editing
tags: added: regression
Changed in inkscape:
milestone: none → 0.49
Revision history for this message
jazzynico (jazzynico) wrote :

Reproduced on Windows XP, Inkscape trunk revision 12832, visual bounding box.
Not reproduced with a geometric bounding box.
Not reproduced with 0.48.4.

What's the expected behavior of the visual bounding box?

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

Attaching two sample files, with different behavior:
1) Exposes the report behavior when stretching the circle vertically:
1254822-stretch-stroked-ellipse-2-not-ok.svg
2) Does not expose the reported issue:
1254822-stretch-stroked-ellipse-2-ok.svg

Difference: the second file has 'Snap smooth nodes' enabled (but no other snap targets, so snapping should not be triggered when scaling).

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

Both files tested with default (new) preferences (i.e. stroke scaling is on), using r12836 on OS X 10.7.5.

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

shoot, I missed my window of opportunity by 2 hours!

     I would like to propose that this bug report be marked as Invalid, because this behaviour is done this way by design. If you choose the option "scalable stroke", and if you do a vertical drag, the intent is that the width of the visual bbox remain constant. However, the stroke is increasing due to the scaling. Therefore the geometric bbox width must decrease, and this is the source of the interaction. The geometric width decrease will be very small if the stroke is small. Exactly the same behaviour occurs in 0.48.4 as well. But there it is not so obvious because it shows up in a transform element, not in the width parameter. However the net effect is the same, the geometric width decreases very slightly due to the stroke scaling, after applying the transform.
     Therefore I think this bug report is invalid. I cannot explain the file stretch-stroked-ellipse-2-ok.svg. All I know is that the code for doing the scaling is in sp-item-transform.cpp in the routine get_scale_transform_for_uniform_stroke(). This particular routine is _not_ being called by the file stretch-stroked-ellipse-2-ok.svg, but I believe it should have been called.

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

P.S. if you load the file 1254822-stretch-stroked-ellipse-2-ok.svg into INkscape 0.48.4 and perform a vertical drag to increase the height, then the interaction shows up as normal. You get a transform that looks like this:
matrix(0.96738259,0,0,1.8180374,6.5234817,-78.541996)
where the 0.967 represents the slight contraction of the width of the geometric bbox. Therefore there has been a change in this specific file, since 0.48.4, and related somehow to snapping, since current trunk does not show this interaction.

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

@Diederik - any chance that you could take a closer look at the issue discussed in this report, and the effect the snap setting has in the provided sample files (comment 2 and 3)?

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

Closing as 'Invalid' as requested by the reporter.

Changed in inkscape:
milestone: 0.91 → none
status: New → Invalid
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.