Measure Path off by a small amount

Bug #348611 reported by Jon Goldberg
4
Affects Status Importance Assigned to Milestone
Inkscape
Fix Released
Low
Unassigned

Bug Description

Measure path is off by a small amount when calculating Feet.

I have a line that has a height of .250 ft. When I put in the measure Path with a scale of 200 it should get 50ft but it gets 49.8 ft. It works with Meters and CM just fine so it must be a rounding error somewhere.

this is in .46 Dev build on 3/17/09

description: updated
Revision history for this message
jazzynico (jazzynico) wrote :

Confirmed on Windows XP, inkscape rev. 21460.

The factor used by measure.py to convert px to ft is 0.2822219/(25.4*12), but according to inkex.py and its uuconv dictionnary (which doesn't support ft, in and yd, but gives some other conversion factors), it should be (1/3.5433070866)/(25.4*12). Other units are also affected.
I've replaced it in the extension, and it seems to work well.

Could someone take a look and patch the extension measure.py in SVN?

Changed in inkscape:
importance: Undecided → Low
status: New → Confirmed
Revision history for this message
jazzynico (jazzynico) wrote :
Revision history for this message
Alvin Penner (apenner) wrote :

fix committed to svn rev 21525.
I took the liberty of rewriting the constants by using the fact that
3.5433070866 = 90.0/25.4

However, apart from this , I think there is a separate issue. It appears that the path is actually modified by the process of measuring it. If I do two consecutive measurements of the same path, I get two different results. If this is still an issue, it might be worthwhile to raise it as a separate bug.

Changed in inkscape:
status: Confirmed → Fix Committed
Revision history for this message
LucaDC (lucadc) wrote :

Sorry, maybe I'm wrong but the constant 90 pixel-per-inch shouldn't be 72 or 96?
For example, on Windows systems (and web browser too) it's usually 96. So in a document it depends on the system resolution and on the zoom factor, so the px unit isn't absolute (that's why I set my template to mm everywhere I could).
If I understood correctly, all internal calculations are done in this 'px' unit and eventually converted to the selected document (interface?) unit, having the px unit been set (arbitrarely) to 90 pixel-per-inch, fixed.

Or are we speaking about points-per-inch? (why 90, anyway? It should depend on the selected document resolution).

I understand using such an internal (arbitrary) unit system to mantain compatibiliy between different systems, but I feel it shouldn't be accessible/selectable by the user, nor have a name that recalls something different.
Not a bug or something to be fixed, indeed (I just avoid using px): I ask only to understand better Inkscape (maybe I'll discover that px is better! :)

Thanks.

Revision history for this message
Alvin Penner (apenner) wrote :

I believe this number comes from the definition of a CSS pixel, which is 90 dpi.

details are given in the file :
C:\Program Files\Inkscape\share\ui\units.txt
and
C:\Program Files\Inkscape\share\ui\units.xml

Revision history for this message
jazzynico (jazzynico) wrote :

Thanks Alvin.
It would be nice to have inkex.py support ft, in and yd, so that we can use it to convert these units in every extensions, and therefore get rid of duplicate code, such as this one...

Changed in inkscape:
milestone: none → 0.47
Revision history for this message
LucaDC (lucadc) wrote :

Thanks for the reply. Unfortunately it doesn't help me to understand.

I didn't know "the definition of a CSS pixel" so I had to look on Internet and found this in 'http://www.w3.org/TR/CSS21/syndata.html#length-units':

"Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the pixel unit refer to the whole number of device pixels that best approximates the reference pixel. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm's length. For a nominal arm's length of 28 inches, the visual angle is therefore about 0.0213 degrees."

Is this the right definition you were speaking about?
Here they recommend "'96 dpi" referring to "pixel density" of a device. It's something much different than the coordinates (or resolution) of a document.
So, is the "px" unit the one corresponding to 1 px on a monitor when the document zoom is set to 100%?
And what does it mean "document zoom at 100%"?
Pixel is not an absolute measue as mm or inch or dpi are: it's relative to a particular device (monitor, printer, camera, etc...). So it's conceptually wrong to define a pixel as some fixed fraction of an inch.
There could be a conventional definition, and under Windows (and web browsers) it's 1/96 Inch. I can't find the 90 anywhere.

I also found: 'http://www.w3.org/Style/css1-updates/REC-CSS1-19990111-errata.html'
Search for 90 and 96.

I've done very quick searches so maybe I'm wrong.

Revision history for this message
Alvin Penner (apenner) wrote :

sorry, I didn't really want to open up a can of worms, just wanted to point out where the documentation for units is. Further discussion can be found at Bug 168753 .

Revision history for this message
LucaDC (lucadc) wrote :

Ok, I understand.
But, please, check the errata document for CSS: it's dated 2001.
If I'm not wrong, 90 dpi _is not_ the current CSS standard. Just rename it to something else or move to 96 which _is_ the current CSS standard.

Just a formal issue.

And, for the future, I suggest that '90' not being so hardcoded (at least now it's not hidden in a anonymous float number: I wonder how many other there could be...).

Thanks.

jazzynico (jazzynico)
tags: added: extensions-plugins
ScislaC (scislac)
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.