Generating dimensions gives wrong results

[Weinar]

Several examples are shown in attachment

[Pablo Trabajos (pajarico)]

Confirmed on WinXP, 0.47pre2.

[Jim Van Zandt (jrvz)]

Confirm with 0.47 .

This may be related to the chosen type of bounding box (counting the stroke width, or not) - see 212768. However, in the above example, the horizontal dimension marks are correct but the vertical dimension marks are wrong, and one would expect the stroke width to affect both.

[su_v (suv-lp)]

I see no difference due to the bounding box setting (visual or geometric) - i.e. it is completely ignored: the extension seems to always use a visual bbox, though not without errors: the bug seems limited to the calculation of the vertical stroke width respectively the difference between a simplified visual bbox and the geometric outline as defined by the geometric mid-lines of the paths. This is incorrect for the vertical dimensions of ellipses and complex curves (doesn't matter if a stroke is defined or a fill color only), but correct for rectangles, polygons, regular paths made from straight line segments and - apparently - non-overlapping curves (e.g. a spiro spline defined by three points or an ellipse converted to a path).

[jazzynico (jazzynico)]

See also Bug #269002 "An LPE to measure area (square) of a closed path"

[Alvin Penner (apenner)]

    The Dimension calculation depends upon a bounding box calculation that is performed in the routine simpletransform.computeBBox. This routine calculates an approximate bounding box, apparently by using the envelope containing all the Bezier control points used to draw the object. This approximation will always be somewhat too large, and can sometimes be significantly too large, as seen in the attached svg file.

[Alvin Penner (apenner)]

 Attached is a modified version of the file dimension.py, in which the computeBBox routine has been replaced by the Inkscape command-line option 'query-width', etc, which appears to solve the problem.
 Could you try this and see if it helps? The file will need to go in the directory \Inkscape\share\extensions\.

[su_v (suv-lp)]

Inkscape 0.47+devel r9440 on OS X 10.5.8, bounding box in 'Tools' preferences set to 'Geometric'.

Inkscape crashes when executing the modified extension if the bbox setting is changed from default 'Visual' to 'Geometric'. (You have to restart Inkscape after changing it so that when the extension calls inkscape to query the selected object the spawned process uses the same setting from the preferences file).

attaching console and crash log.

[su_v (suv-lp)]

crash log from 0.47+devel 9440

(the crash also happens when testing the extension with Inkscape 0.47)

[su_v (suv-lp)]

IMHO dimension lines have to support the geometric bounding box if the extension is meant to be used with technical drawings. Ideally it would be an option (radio buttons or dropdown list) when calling the extension (bbox to use: Geometric/Visual), defaulting to 'Geometric'.

[Alvin Penner (apenner)]

    Cannot reproduce the crash above. It seems to be related to the property "connector-curvature". When I draw an object I do not get this property present in the object. Not sure where it comes from. Attached is a typical output obtained from the new version of dimension.py. This was done with a very thick line width and the Bounding box preference set to "Geometric".
    As far as I can tell, the Bounding box preference setting has no effect on the result. The command-line option for calculating the Bounding box using --query-all will produce the "Visual Bounding Box" result regardless of the preference setting.

[Alvin Penner (apenner)]

this is somewhat OT, but do you get a similar crash if you use the extensions 'Modify Path->Perspective' and 'Envelope'? These extensions all use the same method for calculating the bounding box.

[su_v (suv-lp)]

You are correct - I didn't thoroughly test the changed setting nor inspect the SVG used (see attached). The crash is not due to the geometric bbox setting and the command line option --query-{width|height} apparently always uses the visual bbox. :(

The SVG file in question was created by copying the bezier path from your example file attached to comment #6 into a new file and changing the stroke width to 32px to test the bbox used by the extension. I have no idea how that incorrect property without namespace was added to the path - I never manually edited the file.

[su_v (suv-lp)]

The attribute
       inkscape:connector-curvature="0"
is added to every path in 0.47+devel once it is moved or edited after being created. AFAIK this is caused by the refactored code for the connector tool.

The crash was obviously due to an incorrect attribute
       connector-curvature="0"
and this seems to be caused by the 'Dimension' extension itself:

steps to reproduce:
1) Use a current Inkscape development version, create a bezier path, edit some handles
   (Verify in the XML Editor that the attribute 'inkscape:connector-curvature' has been added)
2) Apply the (modified or old) extension 'Dimension' to the path
3) Verifiy in the XML Editor that the resulting path located now in the group with the dimensioning lines has the incorrect attribute added which will crash Inkscape when reusing that path for a second run of the 'Dimension' extension (after e.g. copy&pasting it into a new document).

[Alvin Penner (apenner)]

yes, I've duplicated the crash, will look into it to see why this is happening

[Alvin Penner (apenner)]

attached is a modified version of the file dimension.py. I've used a different call to create the group that the new elements belong to. This version correctly preserves the inkscape:connector-curvature attribute, as far as I can tell. I have not been able to make it crash. fwiw, the previous version was not correctly preserving any of the inkscape attributes and also not any of the sodipodi attributes.

[su_v (suv-lp)]

Thank you for figuring out what caused the crash and providing a fix for that.

While the results of this version are more consistent in that it always uses the visual bounding box for every type of object (and prevents crashes caused by incorrect object attributes it created itself), I am not sure it is a better solution than the previous version with regard to the intentions when using dimensioning lines: the old version seems to have made an effort to get the geometric definitions of the objects as precise as possible within the limits of the existing library of python scripts, now - based on inkscape's command line query results - suddenly SVG related issues like end-cap attributes of the stroke style and disregarded miters of sharp corners have an influence on what geometry is measured and can make the dimensioning lines appear imprecise again.

IMHO dimensioning either needs an option to choose between both types or the extension is able to respect the preference setting (I do not know whether extension scripts have access to this information). I'm aware this could be difficult to implement. Personally I would either keep a renamed copy of the old extension around (patched with your crash fix) - or - if I had the python skills ;) - try to combine both the old 'imprecise' based on an approximated geometric bbox and the new 'precise' based on the visual bbox into one extension and allow the user to choose the method herself.

[Alvin Penner (apenner)]

attached is a new version of the dimension.py file

[Alvin Penner (apenner)]

this version has a new radio button option to allow the user to choose between the two styles, requires the new .inx file attached

[su_v (suv-lp)]

From my perspective that's better than replacing the old script with 'inkscape --query' - any other comments about this?

@Alvin - is there a chance that the routine from 'simpletransform.computeBBox' can be improved to handle at least circles and ellipses correctly when computing the geometric (enveloping) bbox? I can see why your extreme example can't be easily fixed, but for a (central or reflectional) symmetric shape like a circle or ellipse I don't understand why - even if the Bezier control points are part of the equation - the result differs in the horizontal and vertical dimension (circles or ellipses converted to path get a precise geometric bbox).

[Alvin Penner (apenner)]

two part response: I think the routine in 'simpletransform.computeBBox' can be improved, but that is a bit of a long term project, not something that is likely to get done in the next month or so.

I think, if there is no objection, I would like to commit these changes as they are, although probably it would be best to do this after the release of 0.48 since we are almost in string freeze.

As for the routine 'simpletransform.computeBBox', I believe that it operates by (temporarily) converting all shapes, including circles and arcs and ellipses, into a collection of Bezier curves. So one is actually evaluating the properties of Bezier curves, not the original ellipses. This makes it quite difficult to predict ahead of time how good or how bad the approximations will be. However, evaluating the bounding box of a single Bezier curve can be done precisely, and analytically, so there is no reason why this cannot be done correctly, I would be interested in looking at this over the course of the summer.

[Alvin Penner (apenner)]

attached is a modified version of the file simpletransform.py. With this, I believe the original geometric bounding box option should work correctly.

[su_v (suv-lp)]

@Alvin - assigning this report to you (please object or revert it if you'd prefer me not to ;-) )

First quick tests look fine (have yet to test and compare with the various attached example files).
Thx for looking into this and adding the visual as well as improving the original geometric bbox option!

[su_v (suv-lp)]

Committed in revision 9635.