Geometric and Visual bounding box and object dimensions

[Kwasi]

In the Inkscape 0.46 you can choose to work with geometric (stroke width does not matter) or visual (stroke width included) bounding box.
It would be great if the objects size and position would be depending on the bounding box, so geometric Bbox would report always a smaller or equal sized object as the visual Bbox.

Steps to reproduce:
1. paint a simple box with a thick stroke
2. set inkscape to use visual bounding boxes so the drawn box including its stroke fits into the Bbox
3. look at the dimensions of the drawn box
4. set inkscape to use geometric bounding boxes. now the bounding box will be going through the center of the stroke
5. take notice of the dimensions. they are still the same unless visible the bounding box is smaller.

a work around can be provided by allowing to choose whether strokes are drawn ON the geometric border, or as an INNER or OUTER stroke.

[Diederik van Lierop (mail-diedenrezi)]

When the type of bounding box is changed, the object doesn't change at all. Therefore the dimensions will stay the same and needn't be updated. The only thing that changes is the size of bounding box, but this is not a part of the object. It's only defining where Inkscape draws it handles and where it snaps, so it's just a "tool" that Inkscape uses.

It's not the bounding box that defines the object, it's the object that defines the bounding box!

[Diederik van Lierop (mail-diedenrezi)]

Well, apparently not everyone agrees with me :-). It looks like this has been fixed by Bulia as requested, see

http://inkscape.svn.sourceforge.net/viewvc/inkscape?view=rev&revision=18352

Haven't tested it yet though....

[Matthias_H (mhullin)]

Geometric BB is still acting up, see: https://bugs.launchpad.net/inkscape/+bug/370137

[su_v (suv-lp)]

Confirmed with current SVN builds (0.46+devel r22240, OS X 10.5.8)

When using 'Geometric bounding box' the numeric entry fields of x, y coordinates and bbox height and width in the controls bar of the selector tool don't allow to enter precise values: only after several repeated entries of the same numbers inkscape finally seems to calculate the same values internally and uses the entered numbers. This doesn't happen when using the 'visual bbox' setting.

Reopening this bug and assigning to Diederik (I hope that's ok?) - maybe you could estimate if this is a broader precision issue or could be easily fixed by changing the way the bounding box values are calculated when in 'geometric bbox' mode? This issue makes the geometric bbox mode barely usable for technical drawings IMHO as the workaround to always snap to grid or guides isn't always practical.

related bugs:
Bug #190557 in Inkscape: “resize of object or group by entering a numeric size results in a different size.”
Bug #370137 in Inkscape: “"Geometric bounding box" setting does not affect XYWH edit fields on the Tool Controls bar”

and maybe
Bug #174046 in Inkscape: “Rectangles do not snap accurately to grid”
(the discussion here has a lot of information about the bbox modes and resulting issue (e.g. with snapping or resizing) and really helped me to better understanding the different concepts)

[LucaDC (lucadc)]

Diederik, I tried to understand what's happening but without looking into the code. If you want, take a look at what I wrote on Bug #398715 (which is another one related to this issue so can be marked as duplicate).
Maybe those considerations can help you.
I still think it's a wrong formula somewhere.

Good work.

[su_v (suv-lp)]

Related reports:
Bug #190557 “resize of object or group by entering a numeric size results in a different size.”
Bug #398715 “Resizing objects on toolbar is not precise”:
Bug #452102 “Wrong value set when changing the size of a horizontal (or vertical) line”
Bug #706509 “Endpoint of scaled line segment moves”

[Diederik van Lierop (mail-diedenrezi)]

A fix has been commited in rev. #10403; as of now it should be possible to accurately specify the dimensions when using a geometrical bounding box too.

When however visual bounding boxes are used, and the width is changed for a selection of objects each having a different width, then this is still broken. I am not sure if this can be fixed easily. We could implement an iterative procedure though, to have Inkscape enter the same dimensions 10 times in a row ;-)

[Diederik van Lierop (mail-diedenrezi)]

The latter problem (changing the dimensions of the visual bounding box of selection of multiple objects having different stroke widths) should have been solved as of rev. #10442

@LucaDC: the formula was indeed wrong. It's a simple problem, but still the result is very complex for some reason. I needed to change a simple ABC formula into this:

r1h=(r0h*sqrt(r0h^2*w1^2+((4*h0*h1-4*h1*r0h)*w0+(2*h1*r0h-4*h0*h1)*r0w)*w1+h1^2*r0w^2)+r0h^2*w1+h1*r0h*r0w)/((2*r0h-2*h0)*w0+2*h0*r0w)

r1w=(w0*(r0w*
(h0*h1*sqrt(r0h^2*w1^2-4*h1*r0h*w0*w1+4*h0*h1*w0*w1+2*h1*r0h*r0w*w1-4*h0*h1*r0w*w1+h1^2*r0w^2)-h1*r0h*sqrt(r0h^2*w1^2-4*h1*r0h*w0*w1+4*h0*h1*w0*w1+2*h1*r0h*r0w*w1-4*h0*h1*r0w*w1+h1^2*r0w^2))
+(h0*h1^2-h1^2*r0h)*r0w^2)+w1*
(r0h^2*r0w*sqrt(r0h^2*w1^2-4*h1*r0h*w0*w1+4*h0*h1*w0*w1+2*h1*r0h*r0w*w1-4*h0*h1*r0w*w1+h1^2*r0w^2)+(3*h0*h1*r0h-3*h1*r0h^2)*r0w*w0+(2*h1*r0h^2-3*h0*h1*r0h)*r0w^2)+r0w^2*
(h1*r0h*sqrt(r0h^2*w1^2-4*h1*r0h*w0*w1+4*h0*h1*w0*w1+2*h1*r0h*r0w*w1-4*h0*h1*r0w*w1+h1^2*r0w^2)-h0*h1*sqrt(r0h^2*w1^2-4*h1*r0h*w0*w1+4*h0*h1*w0*w1+2*h1*r0h*r0w*w1-4*h0*h1*r0w*w1+h1^2*r0w^2))
+r0h^3*r0w*w1^2+(h1^2*r0h-h0*h1^2)*r0w^3)/(w0*(r0h^2*sqrt(r0h^2*w1^2-4*h1*r0h*w0*w1+4*h0*h1*w0*w1+2*h1*r0h*r0w*w1-4*h0*h1*r0w*w1+h1^2*r0w^2)-h0*r0h*
sqrt(r0h^2*w1^2-4*h1*r0h*w0*w1+4*h0*h1*w0*w1+2*h1*r0h*r0w*w1-4*h0*h1*r0w*w1+h1^2*r0w^2)+(h1*r0h^2-5*h0*h1*r0h+4*h0^2*h1)*r0w)+h0*r0h*r0w*
sqrt(r0h^2*w1^2-4*h1*r0h*w0*w1+4*h0*h1*w0*w1+2*h1*r0h*r0w*w1-4*h0*h1*r0w*w1+h1^2*r0w^2)+((r0h^3-h0*r0h^2)*w0+h0*r0h^2*r0w)*w1+(-2*h1*r0h^2+4*h0*h1*r0h-2*h0^2*h1)*w0^2+
(h0*h1*r0h-2*h0^2*h1)*r0w^2)

See http://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/10442 for more details; It can be simplified somewhat, but still...

[Diederik van Lierop (mail-diedenrezi)]

BTW, the calculation of the dimensions of the visual bounding box is inaccurate in current releases, see https://bugs.launchpad.net/inkscape/+bug/805793. This is however not related to this bug, which can be closed IMHO

[su_v (suv-lp)]

Regression introduced most likely with r10446 (not reproduced with my latest earlier build 10436): resizing an unstroked shape or path with the mouse crashes when stroke scaling is turned off (otherwise all default settings).

1) default prefs file
2) open new default doc
3) draw rectangle, remove stroke
4) resize with mouse -> ok
5) turn off stroke scaling
6) resize with mouse -> crash

tested with r10436 and r10446 on Mac OS X 10.5.8 (i386), GCC 4.2.1, debug build with -g and -O0

[su_v (suv-lp)]

Note: previously mentioned revision number 10446 no longer applies, apparently the latest revisions have been changed in trunk (several removed and then merged again in r10439).

[su_v (suv-lp)]

… and 10446 was a typo anyway - I wanted to refer to r10442 instead (comment #8).

[Diederik van Lierop (mail-diedenrezi)]

Sorry for the crash, I screwed up here. Should have been fixed as of rev #10443

Thanks for reporting ~suv

[su_v (suv-lp)]

New follow-up report:
Bug #811819 “Crash when changing width/height of a clipped object”

AFAICT regression introduced with r10439 (originally 10442, see comment #8), when stretching a clipped object by changing the width/height values on the select tool controls bar (not triggered when stretching with the mouse).