Undesired scaling effect on borders while resizing elements.

[GoogleCodeExporter]

When resizing objects in SVG-edit, Chromium resizes the object border along 
with the object fill. When releasing the mouse button, the border is 
repainted and everything looks fine again.

I realize that's not very clear. Here's what I did:

1. I made a very tall, red-filled, black-bordered rectangle.
2. I scaled it up horizontally by a large amount.
3. The vertical borders increased in weight dramatically.
4. I let go of the mouse button, and the dramatic borders disappeared, 
making the object a lot smaller than I wanted them.

This is is on Chromium (Google Chrome's FLOSS stepbrother 4.0.256.0, Ubuntu 
build 32803), running trunk from http://svg-
edit.googlecode.com/svn/trunk/editor/svg-editor.html

Original issue reported on code.google.com by wna...@gmail.com on 15 Jan 2010 at 4:04

[GoogleCodeExporter]

Actually this is expected behavior.  I agree it looks a little clumsy, but we 
felt
that consistent border widths were important in more cases than not.

But I also agree that the other behavior (stretching the border) might be 
sometimes
wanted.  Not sure how best to handle that yet.

Here's a hack/workaround to get what you want:

1. make your very tall rectangle
2. rotate the rectangle by a very very small amount (0.01 in the 'angle' box)
3. make some other temporary element (doesn't matter which, small rect/ellipse, 
etc)
4. group the two elements
5. stretch the group horizontally (the rect's vertical border will increase 
dramatically)
6. ungroup the group
7. delete the temporary element

I know this is not fun.  I still haven't figured out in my head how best to do 
this.
 One way might be to allow you to group single elements.  That would eliminate the
need for a temporary element at least.

Original comment by codedr...@gmail.com on 15 Jan 2010 at 4:37

• Changed state: Accepted

[GoogleCodeExporter]

A more obvious fix for this would be to not use transforms at all for scaling 
and
instead just setting the appropriately calculated values on mousemove. 
Something I
actually considered suggesting a while back, but it would require a significant
rework of our code.

I would like to see this solved at some point in the future, as it can currently
appear confusing and a tad hack-ish.

Original comment by adeve...@gmail.com on 20 Jan 2010 at 12:43

• Changed title: Undesired scaling effect on borders while resizing elements.

[GoogleCodeExporter]

Issue 467 has been merged into this issue.

Original comment by adeve...@gmail.com on 8 Feb 2010 at 9:23

[GoogleCodeExporter]

Just wondering if I might re-awaken the discussion about this issue - I 
personally feel it is even more important now that you guys have implemented 
importing and especially now with the image library functionality - as a user 
imports clipart they will undoubtedly want to resize it, which currently has 
some ugly results, especially when reducing dimensions, because the stroke 
weight gets thicker.

Original comment by adrianbj...@gmail.com on 15 Jul 2010 at 10:57

[GoogleCodeExporter]

Actually you'll be happy to know that clip-art SVGs will scale uniformly, so 
you won't see the same behavior there.

Also if you draw new elements with the path lib extension you'll see it keeps a 
constant stroke width, so similar code may help deal with this issue too.

Original comment by adeve...@gmail.com on 16 Jul 2010 at 1:16

[GoogleCodeExporter]

Looks great with the new behavior - thanks :)

Original comment by adrianbj...@gmail.com on 18 Jul 2010 at 12:16

[GoogleCodeExporter]

I think an easy solution for this should exist for Chrome and Opera, which 
support vector-effect:non-scaling-stroke. So we'd want to set that on 
non-matrix elements while they are being manipulated, then make sure the 
selection box doesn't resize inappropriately too (which ideally it wouldn't do 
in the first place...).

Original comment by adeve...@gmail.com on 8 Oct 2010 at 8:23

[GoogleCodeExporter]

Alright! In r1792 there have been two fixes related to this:

1) For all browsers: When resizing the selection box, the side that's not being 
resized will stay in the same position, rather than resizing then snapping back 
on mouseup. I think this should help reduce the confusion.

2) For Chrome, Opera and probably soon Safari, the stroke's scale does not 
change on resize, and nothing changes on mouseup! This leaves Firefox and IE 
with the remaining problem, but at least the selection box will indicate 
exactly what the final size will be.

Original comment by adeve...@gmail.com on 11 Oct 2010 at 5:32

• Added labels: Browser-Firefox, Browser-IE, Priority-Low
• Removed labels: Priority-Medium