Hi, I have been living, breathing, and even dreaming units the past couple of weeks. My understanding of what Inkscape does and what it should do has evolved over the time period but now I think it has pretty much solidified. I thank all those that have given feedback. I've tried to put all this knowledge at one place: wiki.inkscape.org/wiki/index.php/Units_In_Inkscape Conclusions: 1. There are only three attributes that matter: * The SVG root 'width' * The SVG root 'height' * The 'viewBox' Together they define a mapping of the real world to 'user units', in particular they define a scaling factor. Introducing an additional attribute 'svgUnit' is probably unwise. The document class should have a member function that returns the scale based on the above attributes. Note: the SVG spec allows non-uniform scaling and an offset which Inkscape handles without problem so a Geom::Affine should really be returned. 2. The user should be offered the possibility of changing these attributes in a simple way that makes sense to a non-expert: * Change page size: The 'width' and/or 'height' are changed to the new page size with the 'viewBox' changing to keep the same scaling factor. This is what Inkscape does now and has in the past. * Change page scale: The 'viewBox' is changed to set the a new scale factor (the page remains the same size). The GUI should offer the ability to pick a suitable scale factor (e.g. 1 mm == 1 'user unit') from a drop-down menu as well as allow the knowledgeable user to pick a custom scale by setting the 'viewBox' directly (via an expandable section that is normally hidden, like the as is done with the margin settings). Changing the scale factor will result in already existing objects (shapes, paths, text) changing size relative to the page. (Trying to keep the relative sizes constant is difficult and error prone except in the one possible case of wrapping all the content in a group and applying an inverse transform to the group.) With these transforms in mind, it is easy to see what should be done with the 90 dpi to 96 dpi transition. The main problem is for drawings of a specific size like A4 where the width and height are defined in pixels using 90 dpi. To 'fix' these files, change the width and height to use 'mm' or 'in' and then add an appropriate 'viewBox' to set the scale of the 'user unit' to 90 dpi. 3. Guides/Grids/3D Box Tool Guides, grids and the 3D box tool coordinates should be stored as 'user units'. This can be seen by the simple exercise of asking what one would expect to happen under the above transformations: Consider drawing a rectangle, duplicate it and then covert the duplicate to guides. As the page is resized and rescaled one expects the guides to stick to the rectangle's edges. Trunk already has code to define guides in terms of 'user units'. This code should be back-ported to 0.91. It should be relatively easy to handle the 3D box tool coordinates the same way. Grids are a bit more problematic because they allow (actually require) the use of unit identifiers (which are not allowed for guides and 3d box tool coordinates). If the unit identifier is not 'px' then there will be a problem between 0.91 (90dpi) and trunk (96dpi). We can offer an extension to make this conversion for grids and 3D box tool coordinates. Tav