Rectangles do not snap accurately to grid

Yeah, this is a weird one-- Confirmed under Linux in today's SVN 17236.
If you resize the rectangle using the node tool, then it behaves correctly. Must have to do with bounding box calculation?

Diederik can you check this out?

May be related to bug 168002

I will have a look...

It took me some time, but I found out what's going on. And I remember discussing this before with either Bulia (or was it Mental?). Unfortunately I found out back then that this was not easily solved :-(.

What you'll notice is that although stroke scaling is turned off, the stroke will change anyway while dragging. Only after releasing the mouse button the stroke will be restored to its original value. The problem is that the snapping mechanism will use the wrong dimensions because of this, as the snapping calculations are finished before the stroke is reset to its original value..

Well, I don't know if my explanation is fully correct, but I guess you'll get the idea... I couldn't solve this back then, but I think this is worth another look.

The other bug is not exactly the same I think, but it sure is related.

BTW: Tom, thanks for all your effort in triaging these bug reports. That's really valuable!

I've found the email in which I discussed this issue with Bulia, see below. If my analysis is correct (and I'm not fully convinced it is, because this stuff is difficult), then this would be related to:

https://bugs.launchpad.net/inkscape/+bug/sf969406

This is the email:

> - The stroke width scales while dragging, even when the corresponding
> button has been disabled. When releasing the handle everything turns out
> just fine, but while dragging it still looks like snapping wrong. I
> don't think this is due to the selector tool though. Has anyone looked
> into this before?

Certainly. It's one of the oldest bugs in our tracker:

http://sourceforge.net/tracker/index.php?func=detail&aid=969406&group_id=93438&atid=604306

The reason is that for speed, while you are dragging transformation
handle, seltrans does not update the repr of the object, but only the
object itself. Therefore stroke width adjustments are not written to
the object's style. And the display engine takes stroke width from the
style and unconditionally scales it by the object's transform.
Therefore the displayed stroke width grows as you scale it up. Once
you release mouse, stroke width is adjusted and fully written, so the
display becomes correct.

It's me again ;-)

A workaround is to use geometrical bboxes; (Under Inkscape preferences -> tools)

As far as I can tell now, this should be fixable in the selector tool. I've been working on this for about a week now, but I'm not even halfway there (life's been busy). Besides it will require quite some testing because it involves some significant changes in the calculation of the transformations and introduces compensation for the stroke width. Maybe within a few weeks I'll commit a patch aiming to fix this, but by then we will probably be too late for the 0.46 release. Ah, well, too bad...

Now I can confirm that it is definitely going to work! I've got it working at home already, but so far only for scaling. It also needs to be fixed for stretching, skewing, etc. The hardest part has been tackled, but it will probably take a few weeks before I can commit a patch.

However, there's an important design decision to make. Please have a look at the attachment and let me know what you'd prefer.

BTW, Please open it in Inkscape with the grid turned on so you can understand the point I'm trying to make. When viewing it in your browser you will not see the grid!

Diederik: I reviewed your SVG and I honestly don't see a problem to solve here. If I want the nodes to snap, I naturally would use geometric bbox; if I use visual bbox I'm not interested in nodes snapping (at least not while scaling). Both these alternatives are consistent and already work (or at least they should). Your analysis however assumes that someone mixes these two modes - and he will get mixed results, quite naturally, but I don't think we should add some complex on-the-fly switching to work around this. It's much easier to just use consistent bbox/snapping settings. Am I missing something?

Hi Bulia,

Op Ma, 10 maart, 2008 11:25, schreef bbyak:
> Diederik: I reviewed your SVG and I honestly don't see a problem to
> solve here. If I want the nodes to snap, I naturally would use geometric
> bbox; if I use visual bbox I'm not interested in nodes snapping (at
> least not while scaling). Both these alternatives are consistent and
> already work (or at least they should).

You're right about that. If you do it like that then there is no problem.
But currently it is possible to do it differently, and because it's the
default to use visual bboxes, users probably will.

> Your analysis however assumes
> that someone mixes these two modes - and he will get mixed results,
> quite naturally, but I don't think we should add some complex on-the-fly
> switching to work around this. It's much easier to just use consistent
> bbox/snapping settings. Am I missing something?

First I must admit that I haven't though very long about that option yet.
But consider this: if we disable snapping of nodes when the default visual
bbox is used (which is default), then by default we will only be able to
snap the bbox corners and not the e.g. path nodes, text base-lines,
rotation center, corners of stars or rotated rectangles, etc. It's really
only the bbox corners that will snap in such a case.

Of course the issue I explained in the svg file only holds for the
selector tool, and even more specifically only for scaling and stretching
modes because these transformations need an origin. So we could disable
the node snapping for the scaling and stretching, so we can keep it
enabled for the translations and skewing. Wouldn't that limit us too much
though, even if its only for the scaling/stretching? For example, when
stretching a circle it would not be possible to snap the center. I think I
would miss such a feature at some point, but there should be more
convincing examples. I'm not that good at thinking of many different use
cases, probably because I've spend more time on programming than on using
Inkscape ;-)

Diederik

In addition to my previous mail: I'm assuming that the users either simply
prefer the visual bbox mode (for which they could have good reasons) and
at the same time would like to snap to nodes, or just aren't aware of the
visual/geometric option in the preferences. If there's no clear reason to
use the visual bbox combined with wanting to snap nodes, then only an
"education issue" remains

Diederik

Bulia, another consideration: suppose a user is again using visual bboxes in the selector tool, and that has created a path of which the nodes are snapped and aligned to a grid. Next, when translating the path's nodes will snap to the grid again. But when he tries to scale it, the nodes won't snap. We cannot expect that any user would immediately realize that he needs to switch to geometrical bboxes, or can we?

On Mon, Mar 10, 2008 at 9:30 AM, Diederik van Lierop <email address hidden> wrote:
> Bulia, another consideration: suppose a user is again using visual
> bboxes in the selector tool, and that has created a path of which the
> nodes are snapped and aligned to a grid. Next, when translating the
> path's nodes will snap to the grid again. But when he tries to scale it,
> the nodes won't snap. We cannot expect that any user would immediately
> realize that he needs to switch to geometrical bboxes, or can we?

So the question is, do people really need node snapping when scaling.
I'm really not sure of that. Even with ellipse center - scaling an
ellipse to snap its center is imho a very contorted way to act, I
would assume most people would first move it to snap the center and
then scale it around the center, which is much more natural. So I
would vote for disabling node snapping for scaling, perhaps adding a
checkbox to snapping option s, under Snap ndodes, "Snap nodes even
when scaling in Selector" if people want to override that at the
expense of not keeping the origin (as should be explained in the
tooltip).

However, I'm not a heavy user of snapping, so perhaps we need more
input before committing to this.

Wouldn't it be possible to make snapping visual too?
I mean, to make it more consistent, the user could choose between visual mode or geometrical mode and then all settings would work according to bboxes or nodes. I know this could be confusing when changing stroke width but at least every aspect would work either visually or geometrical instead of some things using bboxes and other nodes depending on a lot different settings.
You could even put some sort of expert or advanced button to let experienced users make individual choices for differente settings like geometrical snapping and visual scaling but if the user goes this way they should be know what they're doing.

I am sorry, probably I don't understand the complete issue. Hope this adds something:
I am a big user of snapping, but I always use geometrical snapping. I definitely want *nodes* snapping during scaling (rectangles, paths, whatever). When that functionality is maintained, I am happy.
Now with the snapindicator possibility, it can be made clear to the user what kind of snap was made (I am thinking about showing for example a green node for the node that snapped, when bbox snapped something else)

On Mon, Mar 10, 2008 at 5:35 PM, Johan Engelen <email address hidden> wrote:
> I am sorry, probably I don't understand the complete issue. Hope this adds something:
> I am a big user of snapping, but I always use geometrical snapping. I definitely want *nodes* snapping during scaling (rectangles, paths, whatever). When that functionality is maintained, I am happy.

So, do you also use geometric bbox? If you do, there'll be no loss of
functionality for you. If not, why?

Sorry I was incomplete in my comment. I indeed use geometric bbox. I meant: "If functionality is maintained for geom. bbox setting, I am happy."

Well, clearly no one expressed a real need for snapping of nodes while transforming the visual bounding box. We could therefore let go of this "feature", but I'm not quite ready for that yet ;-). It would have made life easier for me, but when I started this discussion I was already quite far in modifying the selector tool to automagically select the correct origin. I've worked on this a little bit more last evening, and found that it actually works quite well. The origin of the transformations jumps a bit when a node snaps (when using visual bboxes, and scaling of stroke width turned on), but I didn't find this annoying at all (which I expected it to be).

I'll go ahead implementing it like this for transformations other than scaling also. When everything has been sorted out then we can still easily disable this feature in the code if needed, or even have a preference for it. Even when disabled, Inkscape will have gained from this because it makes the selector tool's source code more explicit and versatile. I'll update you all once I've committed this stuff, so you can have a look at it.

Should be fixed as of rev. #18015. Please test, and be very keen on any regressions in the selector tool's handling of transformations! It turned out to be quite a makeover, but it's not very practical to test all possible use cases (visual vs. geometric bboxes, scaling/stretching/skewing/rotating, with or without flipping/mirroring, snapping bboxes or nodes, modifier keys, with or without stroke scaling, etc. which makes at least 128 different combinations)