Thanks for your mail Tav. What you are describing is exactly what Inkscape is doing.
-Johan
On 8-9-2014 21:36, Tavmjong Bah wrote:
I do not have time to study this issue carefully at them moment and to follow who is arguing what... but:
Units should never be used inside an SVG file other than to set the width and height on the SVG root element (and even then it is questionable).
The original intent for including units inside an SVG was so that one could set the size of an object on a display regardless of the display's DPI. This did not catch on. Very few displays returned the accurate DPI information that was needed to make this work. The CSS working group after many long arguments fixed one inch to 96 pixels regardless of the size of the display. This is now written in stone.
I argued in the SVG WG that one should be able to set the number of pixels per inch with a property (like we have for exporting a PNG). This was a non-starter.
If one really wants to use a unit of "mm" then set the width and height of the SVG root in "mm" and provide a 'viewBox' that matches. For example:
<svg width="100mm" height="100mm" viewBox="0 0 100 100">
will give a scale of 1 'user unit' (px) to 1mm.
Tav
On Mon, 2014-09-08 at 12:01 -0700, alvinpenner wrote:
Attached are some aesthetic comments on the difference between the original code and the modified code which preserves the transforms when changing document units. There are two problems that can occur when preserving unit transforms in a layer definition. First of all the operation of changing document units does not commute with the operation of creating a new layer, which is unexpected:
- open Inkscape with default units px
- draw rectangle
- change units to mm
- create new Layer 2
- draw same-sized rectangle
- save as rect_13546.svg
Compare the two objects in the XML editor and note that the second rectangle 'height' and 'width' are expressed in mm as expected. The first rectangle has its dimensions expressed in pixels which have subsequently been transformed to mm. The net result is that the 'height' and 'width' properties are not comparable when viewing them in the XML editor, because the history of how they were produced has been remembered.
Peforming the same operations in rev 13534 we get the file rect_13534.svg. In this file all the properties are expressed in mm, as expected.
Secondly, the impact of the Preference setting for Optimized/Preserved transforms is modified significantly. The above operations were done with the Preference setting "Behavior->Transforms->Optimized". Now we perform the same two experiments with "Behavior->Transforms->Preserved", to produce the files rect_13546_preserved.svg and rect_13534_preserved.svg.
Inspecting the file rect_13546_preserved.svg, we see that for both rectangles, the original coordinates are expressed in pixels, as expected, and in both layers the conversion to mm occurs as a result of a transform, but the first rectangle has the transform in the layer <group> element while the second rectangle has the transform in the <rect> element, so the location of the transform element is not consistent.
Inspecting the file rect_13534_preserved.svg, we see that for both rectangles, the original coordinates are expressed in pixels, as expected, and in both cases the transform to mm occurs in a <rect> element, so the two objects are directly comparable, even in the XML editor.
The conclusion is that the original code in rev 13534 produces a more consistent representation of the two layers.
rect_13534.svg http://inkscape.13.x6.nabble.com/file/n4971483/rect_13534.svg rect_13534_preserved.svg http://inkscape.13.x6.nabble.com/file/n4971483/rect_13534_preserved.svg rect_13546.svg http://inkscape.13.x6.nabble.com/file/n4971483/rect_13546.svg rect_13546_preserved.svg http://inkscape.13.x6.nabble.com/file/n4971483/rect_13546_preserved.svg
hth, Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Please-check-r13544-or-later-for-problems-a... Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Want excitement? Manually upgrade your production database. When you want reliability, choose Perforce Perforce version control. Predictably reliable. http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.cl... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel