Resizing objects on toolbar is not precise

[LucaDC]

I remeber this has already been reported but I can't find where. So I'm filing a new bug report: if someone finds the duplicate feel free to mark it.

Having stroke width not scaling with objects (the button in the toolbar is not pressed), if you use the two input fields W and H to set the size of an object you don't get what you input.
For example:
 - draw a 100 mm x 100 mm square;
 - set its stroke width to 1 mm;
 - edit its W to 50: when you press enter you get 49,49495 mm (and the rectangle is 49,49495 mm large);
 - edit its H to 50: when you press enter you get 49,49495 mm (and the rectangle is 49,49495 mm tall).

If you set the stroke width to 5 mm, after resizing to 50 mm you get 47,368 mm.

The two numbers are: (50-1)/(100-1)*100 and (50-5)/(100-5)*100. So I assume that stroke width is always considered when calculating the multiplication factor for rescaling an object.
Anyway, this is wrong: the correct formula is: (50+1)/(100+1)*100 (or (50+5)/(100+5)*100), then resizing the stroke width back to 1 mm you get 51 total i.e. 50+1 (or 55 i.e. 50+5).
All this if I correctly understood the math under this transformation.

I hope this helps.

[LucaDC (lucadc)]

No, I'm wrong: it's even simpler:
 - the 100 x 100 object with stroke size 1 is actually 101 x 101;
 - we want it to be 50 x 50 with stroke 1, so 51 x 51;
 - but when resizing the stroke first changes: in this case the factor is 1/2 so the new stroke will be 0.5 at first.

The formula is: k = (101 - 1) / (51 - 1) = 100 / 50.
With this you get a 50.5 object with 0.5 stroke width (i.e. the object is 50 without stroke, that's correct).

So the formula in the code is correct if applied to the size of the object with the stroke, but now seems to be applied to the numbers in the W and H fileds in the toolbar that do not consider the stroke.
If you don't consider the stroke the formula is simply: k = newSize/oldSize.
Or you have to add the stroke width before applying the first formula (that's adding to subtract after, but I don't know what's easier to implement in the code).

[su_v (suv-lp)]

Inkscape 0.47pre1 r21720 on OS X 10.5.7: the setting of 'Preferences > Tools > Bounding box to use' influences the used formula:

visual bounding box:
   created rect 100x100 with stroke=1 gets 101x101 with stroke=1 when selected with select tool
   resizes to 50x50 with stroke=1 [mm]
geometric bounding box:
   created rect 100x100 with stroke 1 stays 100x100 with stroke=1 when selected with select tool
   resizes to 49.495x49.495 with stroke=1 [mm]

I remembered a discussion about transformation, scaling & snapping issue in bug #174046, but it doesn't mention the toolbar…

[Daniel Haertle (haertle)]

Inkscape 047pre3 on Windows:
In summary:
with visual bounding box: everything works fine.
with geometric bounding box: formula is wrong; there is no need for a formula, just set W (or H) to the value given by the user.

[LucaDC (lucadc)]

Almost 2 years later...
Rev. 10300, Windows XP SP3

I drew a 20,0 x 30,0 mm rectangle positioned at location (40,0 ; 230,0) mm, 2,0 mm line thickness.
Then I modified the width input field to 25,0 mm and got a 25,556 x 30,0 mm rectangle at location (39,722 ; 230,0) mm, 2,0 mm line thickness.

This is a complete disaster: not only the dimension is wrong, but the rectangle has also moved!

Can anybody explain me why those width and height input fields are editable? Is it just to hurt who doesn't know they are (still) broken?
Inkscape is capable of doing many much more difficoult tasks than resizing an object and those input fields are in the center of the main toolbar: don't they deserve a bit of love?

I'll keep using guidelines and node-snap to draw a rectangle of given dimensions... (sigh!)...

[su_v (suv-lp)]

> I drew a 20,0 x 30,0 mm rectangle positioned at location (40,0 ; 230,0) mm

Please attach a sample file (it is unclear to me if above refers to the visual or geometric bbox, x/y of the original loaction snapped to grid lines or positioned using the select tool controls bar, the object dimensions as shown in the controls bar of the rectangle tool or the dimensions of the selection as shown in the controls bar of the select tool) and provide details about your settings for
- bbox mode
- scale stroke width

There are several reports tracking related issues - it could be due to unit conversion (specially if you use a A4 page size with default units 'mm), to errors compensating the stroke scaling (if stroke scaling is off) or a combination of both (i.e. erratic stroke scaling compensation aggravated by units conversion).

Visual or geometric bbox can (incorrectly) affect the input to x/y/width/height of the select tool controls bar, as does the setting for scaling the stroke width (i.e. if it is off). I'll search for the related report meanwhile…

[su_v (suv-lp)]

Not reproduced with visual bbox,
reproduced with geometric bbox (0.48+devel r10300)

[su_v (suv-lp)]

Bug #190557 “resize of object or group by entering a numeric size results in a different size.” tracks the issue related to the differnt bbox modes.

[su_v (suv-lp)]

Related:
Bug #452102 “Wrong value set when changing the size of a horizontal (or vertical) line” (also mentions the displaced location (X,Y) after 'stretching' the selection (increasing the width or height in the select tool controls bar)).

[su_v (suv-lp)]

A summary of this issue had also been added to the (reopened)
Bug #212768 “Geometric and Visual bounding box and object dimensions”

@LucaDC - would you agree to mark this one as duplicate of either bug #190557 or bug #212768? (Yes, I'm aware that atm it's quite a mess how these issues are tracked in various reports - apologies for that!)

[LucaDC (lucadc)]

The conditions are the same as reported at the beginning (2 years ago): geometric bounding box and unscaled stroke width (actually this is what this whole report is about...).

I just opened a new document (with the above options already set as it's my default) and drew a rectangle randomly (which happened to be black stroke, no fill, 2mm width, which was the last style I used). Then I did what I always do:
 - snap a 45° guideline to the top-left corner;
 - move the guide (relative) of +20,0 mm and -30,0 mm;
 - snap the bottom-right corner of the rectangle to the new guide origin.
Then, as the coordinates of the rectangle were ugly, I moved it (using the X and Y input fields) so they became rounded to X:40,0 and Y:230,0 mm (without affecting width and height). Here I started my test hoping for a surprise that didn't come.

Anyway, I don't see how all this could affect the result: regardless of how and what you draw, if you use the geometric bounding box and don't want line thickness to be resized, the width and height input fields are (still) sadly broken as they have been for at least 2 years.
Better luck in 2013, maybe. ;)

@~suv: if you find an older report related to the same or a similar issue, pardon me for having opened a new one and made you search for it (see the incipit).

[LucaDC (lucadc)]

@~suv: sorry I'm too slow in writing and didn't see your postings in the meanwhile.
Bug #212768 is a good candidate: there's already a link to this one (see the last comment; I didn't remember it, sorry again).
Bug #190557 is older but it seems that the point was not caught in it.

[su_v (suv-lp)]

Linking as duplicate to bug #212768 as proposed, to keep the discussion focused in as few reports as possible.

As always - please add a comment here and revert the duplicate status if you don't agree.