Measure Path returns wrong length, area

[Michael Hawley]

When I use Measure Path to measure the area of a path, it returns the wrong value. In experiments with known rectangles and triangles, the results were consistently too small by a factor of 28.9 (to within 5-6 significant figures), tested with pixels, inches, and millimeters. Length measurements appear to be short by a factor of about 5.376 (closer to exactly the square root of 28.9 than to exactly 5.376). Running 0.48.1 on Win XP SP3.

[su_v (suv-lp)]

Could you attach a sample file with expected (or "known") and unexpected (incorrect) results returned from the 'Measure path' extension? Mostly it would be of interest whether the SVG file originally had been created in Inkscape (including the paths with "known" dimensions), or whether this might a confusion between the visual and geometric bounding box mode in Inkscape.

[su_v (suv-lp)]

- a sample file
+ a sample SVG file (if the original is based on a different vector format - please attach both the SVG file used for measuring and the original file)

[Michael Hawley (tiedyemike)]

The attached file (derived from the file in question) contains the error. Attempts to recreate the problem with a file I created in Inkscape showed no error. Copying everything into a new Inkscape file fixed the problem, so I have a workaround now.

[su_v (suv-lp)]

> width="2500"
> height="1437.5"
> viewBox="-75 -50 465.04091 170.99168"

Your SVG file uses a viewBox attribute [1] which changes the scale of the drawing (as intended by the SVG specification). Inkscape has partial support for the 'viewBox' attribute: it does not write such an attribute to the top-level <svg> node (but respects it if present when rendering an SVG file). The viewBox attribute must have been created by a third-party application which generated the original SVG file.

It appears that the extension does not support the viewBox attribute, but uses the dimensions as stored in the 'd' attribute of the measured path (including any preserved transforms applied to parent nodes).

[1] <http://www.w3.org/TR/SVG11/coords.html#ViewBoxAttribute>

[Alvin Penner (apenner)]

attached is a new version of measure.py, which is used for the Measure Path extension. This version will take account of the viewBox and also any transform elements that are present in the object. In order to use this, it will need to be copied into the \Inkscape\share\extensions\ directory.

[Michael Hawley (tiedyemike)]

Now it's returning the right answer. It's also wrapping it around the edges of the shape. Is there a consistent way to stop that?

[Alvin Penner (apenner)]

which one is causing the problem, the area or the length?

there are perhaps some minor adjustments that could be made in the positioning of text, and also this may be preventible by specifying a smaller font size, but in general this is hard to avoid because it is using something called TextToPath which molds the text to the associated object.

[Michael Hawley (tiedyemike)]

Both length and area are doing it, whereas I think only length did it before. Yes, smaller text makes it more sensible to look at, so I'm not really that concerned about it, especially now that I've figured out it can be selected with the text tool and straightened with 'Remove from Path'. Still, a checkbox would be a nice feature. Also, while the given lengths/areas are now correct, font size is still affected by the scaling factor (setting font size to 20px still results in text about 100px high).

[su_v (suv-lp)]

> font size is still affected by the scaling factor

Possibly related to / same as
Bug #772057 “Inconsistent handling of parent transforms or 'viewBox' attribute in text tool controls”
<https://bugs.launchpad.net/inkscape/+bug/772057> (comment #5)

[su_v (suv-lp)]

> Possibly related to / same as (…)

Never mind - AFAIU it's about the font size set in the extension dialog, which could consider the scale factor of the viewBox attribute, too.

[su_v (suv-lp)]

@Alvin - the new version does put the 'Area' measurement on path too, whereas the current script (in 0.48.1 and trunk) does not (it positions it at an approximated center, IIRC -> discussed in bug #269002)

[Alvin Penner (apenner)]

- yes, with respect to font size I see now that it is being affected by the viewBox, I'll try to post a new version tomorrow to deal with that.

- with respect to the positioning of the text I was forced to abandon my previous attempt to position the text in the center for the case of an area calculation. This worked only if there were no transforms of any sort. As soon as there was a transform on the top level group then the positioning went bad. (Also went bad when changing page size). The Text on Path position for text, on the other hand, automatically follows the path without requiring any special treatment. So I switched both texts to be Text on Path just to keep it simple. One of them is at the start of the path and the other one is at 50% of the path. Also, when I used my own text element with <tspan> then the xlink:href didn't work, this apparently is not a legal property of text, but works only for TextOnPath

- anyways, will post a new version tomorrow

[Alvin Penner (apenner)]

attached is a modified version of measure.py.
- the font size is adjusted to compensate for the viewBox
- for the Length option, the positioning of the text has been adjusted to try to avoid the right-angle corner in the center of the text

[Michael Hawley (tiedyemike)]

Great to see such fast fixes!

[Alvin Penner (apenner)]

good to hear, committed to bzr rev 10414

[su_v (suv-lp)]

Could the label for the length still use the middle anchor (instead of start), to really center it on e.g. a measured dimension line?

[su_v (suv-lp)]

I really need to read the comments more carefully ;)

> - for the Length option, the positioning of the text has been
> adjusted to try to avoid the right-angle corner in the center
> of the text

Hmm, seems to be conflicting use cases for the extension. Nevermind my proposed revert of your change then, I'll fix it in my local copy for now.

[Louise Balmforth (louise-v)]

The PY posted by Alvin above fixes the gross inaccuracy I was getting on windows 7 brilliantly, however it seems the script fails completely with an error on Mac computers.

They are using OS-X Snow leopard - 10.6.8

Any chance that anyone knows how to fix this issue on Mac OS-X, I have tried changing the

locale.setlocale(locale.LC_ALL, '' )

Line to various suggestions found on the big google including changing it to

locale.setlocale(locale.LC_ALL, locale.getdefaultlocale())

As well as a number of other strings such as 'en_US.UTF-8' and variants of such all of which produce the same error

What I know about Python can be written on the back of a postage stamp with a jumbo marker so I am at a complete loss as to what to do, if anyone can help I would be extremely grateful :)

The error message attached.

[Alvin Penner (apenner)]

I am a little surprised to see version 2.5 of Python in the error message. I thought that Inkscape had been using version 2.6 for some time now. Which version of Inkscape are you running on the Mac? and which version of Inkscape on Windows 7?

[Louise Balmforth (louise-v)]

I am using 0.47 on windoze 7 64bit and it works fine for me.

My friends are using Version 0.48 in mac OS-X, I think two different OS-X versions.

I have fixed (bodged) it for now by simply commenting the offending line out completely, it does not appear to make any difference on windows and on the Mac it now works. As to wither that will cause problems further down the line I do not know?

[Alvin Penner (apenner)]

as far as I can tell, that particular line, referring to locale, was added in rev 2218, on Jan 16, 2007. Have they ever attempted to run this extension before, on a Mac, and has it ever worked successfully before? If it were my machine, I would upgrade Python to something like Python 2.6.6, but I am not a Mac user so I better stop before I say something I might regret. iirc Python comes packaged with Inkscape on Windows, but needs to be installed separately on a Mac (I think).

[Louise Balmforth (louise-v)]

I have no idea, I know less about mac's that I do about Python which means I know absolutely nothing!

It is working without the line so unless it spits the dummy out I will leave it at that, I will suggest they may need to look into updating Python (at their own risk LOL)

[su_v (suv-lp)]

> it seems the script fails completely with an error on Mac computers.

The issue with the locale error on Macs was discussed in the comments of bug #406662.

[su_v (suv-lp)]

> I will suggest they may need to look into updating Python (at their own risk LOL)

Don't.

[Alvin Penner (apenner)]

sorry about that, I should have refrained from commenting.

[Louise Balmforth (louise-v)]

All is fine, I have not contacted the Mac users regarding updating python :)

[paul beard (paulbeard)]

I think OS X 10.6.x used at least 2.6, if not 2.7, as the default python installation. Not sure how 2.5 fits in here. My virtualized copy of 10.6.8 has 2.6.1 installed. If they are using 10.6, I'd like to know how or why they are using older versions of tools like python.

I just installed the modified measure.py and it's better but still not what I would call accurate. A circle 100mm in diameter should have a circumference of 314.159 etc., not 314.202648 mm. Likewise a rectangle 100 x 25 should be 250mm, not 248.871119 mm.

Other than sneering at an unfamiliar OS, is there some actual test of the internals of python that can be compared across different releases and operation systems?

This is what a 10.6.8 system gives me:
uname -a
Darwin virtual-experience.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386
virtual-experience:~$ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

As for the system where I am seeing this bug:

uname -a
Darwin 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
(<email address hidden>)-(11:01 PM / Sun Jun 16)
[/Users/paul]# python
Python 2.7.2 (default, Oct 11 2012, 20:14:37)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin
Type "help", "copyright", "credits" or "license" for more information.

[paul beard (paulbeard)]

I just tested this in FreeBSD 8.4 (Inkscape .4.8.4) and got the same values as in OS X for the file I attached.

Python 2.7.5 (default, Jun 11 2013, 16:22:50)
[GCC 4.2.1 20070831 patched [FreeBSD]] on freebsd8

A line (bezier curve) 100mm in length is measured at 99.72.

I took a look at the Wrongpaths.svg file and I get the right measurements for area for the squares the OP used in FreeBSD but they're off in OS X. So there is something going on. Measurements for simple polygons are fine but arcs or curves are not. Half of a 100mm circle should be half the circumference — 314.15 / 2 — not 44.24 mm.

[su_v (suv-lp)]

On 2013-06-17 08:06 +0100, paul beard wrote:
> Other than sneering at an unfamiliar OS, is there some actual test of
> the internals of python that can be compared across different releases
> and operation systems?

Install the attached extension into '~/.config/inkscape/extensions' on
Linux/OS X (or into '%APPDATA%\inkscape\extensions' on Windows) and
restart inkscape - the new item
 'Extensions > Debug > Python module info'
will report data about the python process actually spawned by Inkscape
(Python version, path of the python binary, environement, version of
modules 'lxml' and 'numpy').

[paul beard (paulbeard)]

OS X doesn't use standard out/error on native applications, at least not that I have seen. Can we specify a logfile to write to in that extension?

[su_v (suv-lp)]

<off-topic>
Did you at least try to install and run the extension on OS X?

[ I wrote it on OS X, and it works for me on Ubuntu (VM), Mac OS X 10.5.8 and OS X 10.7.5 with official Ubuntu and Mac OS X Inkscape packages as well as with various local regular builds of Inkscape stable and trunk), with various Python versions (on OS X those installed by Apple as well as those installed via MacPorts) ]
</off-topic>

[paul beard (paulbeard)]

If I hadn't, how would I know that the output didn't go anywhere? It's not particularly helpful to reply with "works for me" without any information about how to verify how it works. Where does the output go? To the syslog? To the terminal?

OS X applications run from the UI don't connect to a terminal session so it's not clear where the output would be sent. Running the older X11 versions doesn't do much good, as running from the Terminal doesn't pick up all the UI elements.

[paul beard (paulbeard)]

So these don't run as part of Inkscape, they're just a reporting tool? I assumed since they were in an extensions directory that they were accessed by Inkscape and output inform as it worked.

Running them by themselves yields a lot more information than anyone else needs:
Default Encoding: ascii
----------------------------------------
Filesystem Encoding: utf-8
----------------------------------------
Platform: darwin
----------------------------------------
Python sys.version_info: 2.7.2
Python sys.version:
2.7.2 (default, Oct 11 2012, 20:14:37)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)]
----------------------------------------
Python sys.executable:
 /usr/bin/python
Python sys.exec_prefix:
  /System/Library/Frameworks/Python.framework/Versions/2.7
Python sys.prefix:
 /System/Library/Frameworks/Python.framework/Versions/2.7
----------------------------------------
sys.path:
 /Users/paul/.config/inkscape/extensions
 /Library/Python/2.7/site-packages/setuptools-0.6c11-py2.7.egg
 /Library/Python/2.7/site-packages/lxml-3.0.1-py2.7-macosx-10.8-intel.egg
 /Library/Python/2.7/site-packages/pip-1.3.1-py2.7.egg
 /Library/Python/2.7/site-packages/googlecl-0.9.13-py2.7.egg
 /Library/Python/2.7/site-packages/gdata-2.0.18-py2.7.egg
 /Library/Python/2.7
 /usr/local/lib/python2.7
 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python27.zip
 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7
 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin
 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac
 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages
 /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python
 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk
 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old
 /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload
 /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC
 /Library/Python/2.7/site-packages
----------------------------------------
lxml path: /Library/Python/2.7/site-packages/lxml-3.0.1-py2.7-macosx-10.8-intel.egg/lxml
LXML_VERSION: 3.0.1.0
LIBXML_VERSION: 2.7.8
LIBXML_COMPILED_VERSION: 2.7.8
LIBXSLT_VERSION: 1.1.26
LIBXSLT_COMPILED_VERSION: 1.1.26
----------------------------------------
numpy path: /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/numpy
numpy version: 1.6.1
----------------------------------------
os.environ:
_
 /usr/bin/python
VERSIONER_PYTHON_PREFER_32_BIT
 no
TERM_PROGRAM_VERSION
 309
LOGNAME
 paul
USER
 paul
HOME
 /Users/paul
PATH
 /Library/Frameworks/Python.framework/Versions/Current/bin:/Library/Frameworks/Python.framework/Versions/Current/bin:/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin:/bin:/usr/local/mysql/bin
DISPLAY
 /tmp/launch-p76fFC/org.macosforge.xquartz:0
TERM_PROGRAM
 Apple_Terminal
LANG
 en_US.UTF-8
INFOPATH
 :/opt/local/share/info
TERM
 xte...

[paul beard (paulbeard)]

And:
Default Encoding: ascii
----------------------------------------
Filesystem Encoding: UTF-8
----------------------------------------
Platform: freebsd8
----------------------------------------
Python sys.version_info: 2.7.5
Python sys.version:
2.7.5 (default, Jun 11 2013, 16:22:50)
[GCC 4.2.1 20070831 patched [FreeBSD]]
----------------------------------------
Python sys.executable:
 /usr/local/bin/python
Python sys.exec_prefix:
  /usr/local
Python sys.prefix:
 /usr/local
----------------------------------------
sys.path:
 /usr/home/paul/.config/inkscape/extensions
 /usr/local/lib/python2.7/site-packages/distribute-0.6.35-py2.7.egg
 /usr/local/lib/python2.7/site-packages/zope.interface-3.8.0-py2.7-freebsd-8.4-RELEASE-i386.egg
 /usr/local/lib/python2.7/site-packages/nose-1.3.0-py2.7.egg
 /usr/local/lib/python2.7/site-packages/MarkupSafe-0.15-py2.7-freebsd-8.4-RELEASE-i386.egg
 /usr/local/lib/python2.7/site-packages/Pygments-1.6-py2.7.egg
 /usr/local/lib/python2.7/site-packages/Babel-0.9.6-py2.7.egg
 /usr/local/lib/python2.7/site-packages/Jinja2-2.6-py2.7.egg
 /usr/local/lib/python2.7/site-packages/Sphinx-1.1.3-py2.7.egg
 /usr/local/lib/python2.7/site-packages/pyasn1-0.1.4-py2.7.egg
 /usr/local/lib/python27.zip
 /usr/local/lib/python2.7
 /usr/local/lib/python2.7/plat-freebsd8
 /usr/local/lib/python2.7/lib-tk
 /usr/local/lib/python2.7/lib-old
 /usr/local/lib/python2.7/lib-dynload
 /usr/local/lib/python2.7/site-packages
 /usr/local/lib/python2.7/site-packages/Numeric
 /usr/local/lib/python2.7/site-packages/PIL
 /usr/local/lib/python2.7/site-packages/gtk-2.0
 /usr/local/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info
----------------------------------------
lxml path: /usr/local/lib/python2.7/site-packages/lxml
LXML_VERSION: 3.1.0.0
LIBXML_VERSION: 2.8.0
LIBXML_COMPILED_VERSION: 2.8.0
LIBXSLT_VERSION: 1.1.28
LIBXSLT_COMPILED_VERSION: 1.1.28
----------------------------------------
numpy path: /usr/local/lib/python2.7/site-packages/numpy
numpy version: 1.7.0
----------------------------------------
os.environ:
LC_CTYPE
 en_US.UTF-8
SSH_CLIENT
 192.168.0.4 50224 22
LOGNAME
 paul
USER
 paul
PATH
 /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/paul/bin
HOME
 /home/paul
DISPLAY
 localhost:10.0
TERM
 xterm-color
SHELL
 /usr/local/bin/bash
SHLVL
 1
BLOCKSIZE
 K
FTP_PASSIVE_MODE
 YES
EDITOR
 vi
ENV
 /home/paul/.shrc
_
 ./py-info.py
SSH_TTY
 /dev/pts/0
OLDPWD
 /home/paul
CLICOLOR
 yes
PWD
 /home/paul/.config/inkscape/extensions
MAIL
 /var/mail/paul
SSH_CONNECTION
 192.168.0.4 50224 192.168.0.25 22
PAGER
 more
----------------------------------------
bar from foo failed to load.
----------------------------------------

[su_v (suv-lp)]

<off-topic>
The output of the extension 'Python module info' is piped back to inkscape (as happens with every other Inkscape extension), and for this one represented to the user in a pop-up dialog which displays the messages returned by the python script to stderr.
</off-topic>

[paul beard (paulbeard)]

Unless, of course, it isn't. See comments 30 and 32.

[Alvin Penner (apenner)]

running Windows 7, and Inkscape 0.48.4, I have not been able to reproduce the problems mentioned in comment 27.
- part of the problem may be related to the use of mm rather than pixels. In Inkscape, the native unit is the pixel, so any use of mm requires two separate conversions. One conversion will be done in C code in the gui, to convert from mm to px. Then the second conversion will be done in Python, in the Measure extension, to convert from px back to mm.
- part of the problem may also be related to the fact that the gui will sometimes report a visual bounding box size, which includes the stroke width, where you need to see the geometric bounds in this case. The geometric bounds can be obtained from the XML editor.

In any event, attached is a demo obtained in Inkscape 0.48.4. In all cases, the dimensions were confirmed in the XML editor, just to make sure they were correct.
- circle radius = 100 px. Expected circumference = 628.31853, actual calculation = 628.3263, error = 0.001 %, which is noticeably less than the error reported in comment 27, which was about 0.013 %.
- rectangle width = 100, height = 25 px. Circumference = 250 px.
- line horizontal distance = 200, vertical = 150 px, length = 250 px.
- in both cases the calculated length from the measure extension agrees with the expected

[paul beard (paulbeard)]

I saw the conversion/internal use of pixels bug when I was looking at the example and trying some of my own. Trying to create an object of 100 px requires 2-3 tries to go from 99.997 to 100.003 and then to 100.00. Yes, those are small variances but why should a keyed-in value magically change and require re-keying?

The variances I found on my system were greater but I'm just going to have to work around it. If I were to use the "measure all paths" extension to do job costing, I would be off a bit. This example file comes in at 1128 px but 318 mm. Unitconversion.org returns 1203.628346457. For 1128 px it returns 298.45 mm. On a simple example like this one, 20mm may not seem like much, less than an inch but still 6%.

With a more complex file, with 5307 mm of cuts, I get 20,058 px via the unitconversion website, 18,807 in inkscape natively. That 9%. Which is more reliable, to have Inkscape measure in pixels and do conversions outside of inkscape?

[Alvin Penner (apenner)]

two questions:
- I do not see an example file, is it supposed to be attached here?
- I am not aware of a "measure all paths" extension. Where is it located? Is it part of a standard Inkscape installation?

[paul beard (paulbeard)]

1. No, I used yours and added a few objects to verify what I was seeing. I didn't upload it.

2. http://authenticinvention.com/authentic/?p=252 No, it isn't, though it's based on the measure path extension.

So measurements are stored as pixels, no matter what document preferences are selected? Is that subject to review/modification at any point?

[Alvin Penner (apenner)]

>> http://authenticinvention.com/authentic/?p=252 No, it isn't, though it's based on the measure path extension.

with respect to this code, it would be best to submit a bug report directly to the creator of this code, since it is not necessarily the same as what Inkscape is using.

>> So measurements are stored as pixels, no matter what document preferences are selected? Is that subject to review/modification at any point?

not likely, since the svg file that is created by Inkscape uses pixels as the standard unit, and similarly the XML editor does as well.

[paul beard (paulbeard)]

I have tried contact them, but to no avail so far. He says in his description he relied on the Measure Path extension, either as a model, or directly as a data source, so I think it still comes down to how Measure Path works.

I understand that at present inkscape uses pixels internally but is it possible that will change? To me, this passage "the svg file that is created by Inkscape uses pixels as the standard unit, and similarly the XML editor does as well" is better phrased as "the developers who devised the svg file format used by Inkscape chose pixels as the standard unit, as well as for the XML editor." Someone made that decision and I suppose it could be revisited.

I wasn't aware pixels were the fundamental unit. For inches, it's a straight 90:1 conversion but what about metric? 1 millimeter = 3.779527559 pixel? Yikes. I suppose I could convert everything to pixels and adjust everything to fit.

I hope the choice of unit is refactored to be document-specific, rather than requiring laborious conversions.

[rant (ugajin)]

Thanks louise-v

See #239599