Guides positions not stored in user unit (precision)

[LucaDC]

Open the A4 template which defines user unit as mm or set mm as default unit in the default template. Drag a guide and explicitly set its absolute position to 10,10 (mm, of course; not worth specifying this as it's the default unit) entering the coordinates in the X and Y fields of the "Guideline" dialog with "Relative change" unchecked.

In the saved document the guide position is stored as:
   position="35.43307,35.43307"
that corresponds to 10,10 mm calculated in px @ 90 DPI, arbitrary numbers unrelated to the document content.

The correct output should be:
   position="10,10"
to be interpreted considering the user unit:
   units="mm"
and coherently with the specified document extent:
   width="210mm"
   height="297mm"
   viewBox="0 0 210 297"
without any additional conversion.

Among other annoyances, this discrepancy causes rounding errors during the conversions of guides' positions to user unit, affecting all objects that are subsequently snapped to them.
For example: in the A4 template manually place 2 guides at 200,297 and 210,287 (10x10 aligned to the upper right corner of the page), save the file, reload it, draw a rectangle between the two origins and save again; the rectangle is stored in the file as:
    <rect
       style="..."
       id="rect..."
       width="10"
       height="10.000009"
       x="200"
       y="-5.9266667e-006" />
where 'height' should be "10" and 'y' should be "0".
This makes guides useless for snapping objects and have them getting exact coordinates in the final document, as is usually required in technical drawings. Lowering the output precision is not always a viable solution because it may affect nodes that really need more digits after the dot (e.g. a small complex symbol where only the origin is of interest to be "clean" or guides snapped to intersections where the highest available precision is expected).

If repeating the preceding example without saving and reloading the file before drawing the rectangle, the output is slightly better because 'height' is correctly stored as "10" but 'y' is still "wrong": this makes me think that there probably are also problems in managing objects' coordinates internally while storing and elaborating them in RAM. IMHO everything should be done in user unit, to always preserve the final output at best.

Results obtained with:
   inkscape:version="0.91pre2 r13564"

[su_v (suv-lp)]

Related/similar: bug #bug #1235279

[LucaDC (lucadc)]

An update with Rev 13852.
Now guides are stored in user coordinates, but it seems that they are still internally managed using a different scale and converted on save:
 - start from the A4 template: mm as default unit;
 - drag a guide and open its dialog to manually set its absolute position to 10, 10 (mm);
 - save and inspect the file:

      <sodipodi:guide
             position="9.9999998,10"

The correct data should be:

      <sodipodi:guide
             position="10,10"

[Alvin Penner (apenner)]

>> Now guides are stored in user coordinates, but it seems that they are still internally managed using a different scale and converted on save:

This comment can be confirmed also in an alternate way.
- running Windows XP, Inkscape rev 13849
- start from the A4 template: mm as default unit;
- run the menu item Edit->Create Guides Around the Page
- this will create 4 guides. In the XML editor, two of them will have positions given by (210,297.00001) and (0,297.00001) where it should have been just 297 in both cases.

[Alvin Penner (apenner)]

a similar problem occurs in the creation of grids:

 - running Windows XP, Inkscape rev 13849
 - start from the A4 template: mm as default unit;
- open document properties
- click on grids tab
- click on rectangular grid "New"
- set Origin X = 10, Origin Y = 10
- save file
- in the saved file, the grid will have the properties:

       originx="9.9999998"
       originy="10"

which should both be 10.

[Alvin Penner (apenner)]

a similar problem is encountered when manually entering the coordinates of a Bezier path point using the gui:

 - running Windows XP, Inkscape rev 13849
  - start from the A4 template: mm as default unit;
- use the Bezier tool, shift F6, to manually draw a single straight line
- click on the Node tool, F2, and click on a node so that it is editable at the top spinboxes:
- set the coordinates of one node to be some integer values like (0,0)
- set the other node coordinates to be some integer values like (10,10)
- save as node_1010.svg, attached here
- interrogate the file to get the path: we find
  d="m 0,297.00001 9.9999998,-10"

this contains two round-off errors, both in 297.00001 and 9.9999998

[Alvin Penner (apenner)]

- in rev 13868, a fix has been committed for comments 2, 3, and 4.
- comment 5 is still unresolved

[Alvin Penner (apenner)]

comment 5 has been fixed in rev 13876.

the fix makes use of the fact that the scaling equations simplify a great deal in the special case of uniform scaling, so this is treated separately as a special case.

[su_v (suv-lp)]

Related changes (user units for guides):

1) Initial implementation (Tavmjong Bah)
   see also: bug #1400702 (backported to 0.91)
Rev 13769: Use SVG width/height and viewBox to correct guide position.
Rev 13771: Correct guide placement when created by dragging onto canvas or by creating guides around object/page.
Rev 13795: Change grids to use 'user units'.

2) Later commits to improve precision (Alvin Penner)
   (not backported to the stable release branch)
Rev 13868: improved precision in placing grids and guides. (Bug 1373311)
Rev 13876: for viewbox scaling, revert revs 13581, 13582, 13859, and handle the case of uniform scaling as a special case. (Bug 1373311)

@Alvin - since bug 1400702 already tracks Tav's initial implementation and its backport to 0.91 to support storing guides and grids in user units, this one could be assigned to you, tracking the later related commits (if you agree).

[Alvin Penner (apenner)]

okay, sounds good to me, I wasn't sure whether Tav's work had been recognized elsewhere