Resizing path with mouse while snapping nodes to grid can corrupt path

Bug #808558 reported by su_v on 2011-07-11
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Diederik van Lierop

Bug Description

With the recent changes (stroke applied before transformation), scaling an object (regular path) with these settings can result in "corrupt" path data:

- visual bbox
- snap nodes or handles to grid
- no stroke scaling
- default snapping preferences

It seems that the 'visual' (now non-uniform) stroke scaling that occurs while dragging the selection handle (AFAIU bug #165727) can result in path data values which cause the canvas/scrollbars to flicker and/or the scaled object to temporarily "disappear". If releasing the mouse in such a moment, the object "disappears" and can no longer be rendered on-canvas properly.

See attached file for such a corrupted scaled path: I started with a closed rectangular path (~100 x 100 px), stroke width 10 px, and scaled it with the mouse by dragging the upper right transformation arrow and letting it snap to the grid (all inside the visible page border i.e. an aera of 400 x 400 px). At some random point the object disappeared and I released the mouse button, and saved the drawing. Open the file, use <TAB> to select the path and try to zoom to selection…

I failed to reproduce it when hiding the grid (all other settings unchanged) - i.e. no snapping occurs while resizing.

Not reproduced with Inkscape 0.48.1, 0.48+devel r10325
Reproduced with latest revision of cairo-rendering branch r9598
and current trunk (revisions tested: r10391, r10932, r10439)
on Mac OS X 10.5.8 (i386)

su_v (suv-lp) on 2011-07-11
description: updated

Confirmed, although it takes some patience to reproduce.

Changed in inkscape:
status: New → Confirmed

This was probably caused by rev, #10326, in which NR_HUGE was replaced by Geom::Infinity()... Which is not the same

Fix committed in rev. #10458

Changed in inkscape:
status: Confirmed → Fix Committed
assignee: nobody → Diederik van Lierop (mail-diedenrezi)
su_v (suv-lp) wrote :

thx - no longer reproduced with latest build (r10460).

Changing status to 'Fix Released' in accordance to [1] - the reported issue never occurred in a released version, only in current trunk.

[1] <>

I noticed (in trunk) that the snap indicator symbol - if it happens to indicate the origin (0,0) of the GUI coordinate system - is offset (down and to the right) or even disappears. Can you reproduce this, and should I file a report about it, or is it too minor an issue (cosmetic) to be addressed?

Changed in inkscape:
importance: Undecided → Medium
status: Fix Committed → Fix Released

Thanks for the explanation of the "fix released" status, never though too long about that.

The (0,0) issue has been fixed in rev. #10463. I believe this also fixes lp:360158 :-)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers