Hi,
It has been hard to keep track of everything going on with units in the past couple of days. I've got some comments about what has been done and where we should be headed. Please add your comments.
1. 'display_units'
I think we all agree that inkscape:document-units is meant to be 'display_units'. Johan's changing of 'doc_units' to 'display_units' should make this much clearer. Thanks Johan!
(BTW, I change 'units' to 'page_size_units' last week for similar reasons.)
2. 'svg_units'
I am not sure about what this actually means. The comment is:
// Units used for the values in SVG
Is this the suppose to be the unit identifier used inside the SVG file? The only time that would be useful is if the 'user unit' has a real world value of 1px otherwise unit identifiers don't mean what users would expect them to.
Or is this the unit identifier in the root 'width'/'height'. In this case, I think it might be useful to take a step back and look at the a more global picture. The root SVG values of 'width' and 'height' along with the 'viewBox' establishes the scale for the drawing. Typically one has:
<svg width="20mm" height="20mm" viewBox="0 0 20 20" ...>
where the 'user unit' is equivalent to 1mm. But one could also have a valid file with:
<svg width="20mm" height="20mm" viewBox="0 0 40 40" ...>
where the 'user unit' is equivalent to 0.5mm.
We really should support arbitrary scaling (including non-isotropic). So instead of an 'svg unit' we should have an 'svg scale'. (Our rendering already supports arbitrary scaling so it would be a shame if our GUI didn't too, see the example SVG below.)
3. % values on root 'width' and 'height'
I saw something on IRC about % values on the root SVG 'width' and 'height'. This is actually a very common use case for web designers where the SVG is to automatically fill a space. Inkscape treats % values on the 'width' and 'height' by using the values from the 'viewBox' (or if there is no 'viewBox' it assumes all values are in pixels). Here is an example of where 'width' and 'height' are in % and the scaling is non-isotropic. Inkscape renders it just fine:
http://tavmjong.free.fr/SVG/TEST_IMAGES/root_percent.svg
4. Precision
The SVG spec says that values like length are floats and this is indeed what we use internally in Inkscape. I am wondering if we should change this to double as it would make internal calculations more precise. This might avoid some of the rounding errors when switching units back and forth from say 'mm' to 'pc'.
We allow the user to set the numerical precision to up to 16 digits. This makes little sense given that floats are good to only 6 or 7.
5. Converting between 90/96 dpi
I think our focus here is to do the minimum possible to convert an SVG file between 90 and 96 dpi. Trying to scale everything inside the file is rarely going to work satisfactory for a file of any complexity. Here are some things we should try (I am brain storming here):
a. Add a 'viewBox'
If a file has been created to a specific size using only user units, say A4 at 90dpi, using on user-units then one can set the SVG root to be:
<svg width="210mm" height="297mm" viewBox="0 0 744.09448819 1052.3622047" ...>
b. Absolute sizes are really only important for producing printed matter. We could add a 'dpi' factor. Values must be converted in PDF/PostScript export from 90 or 96dpi to 72dpi. The conversion factor could be user selectable. (Although adding a 'viewBox' as above should take care of this.)
c. Grids and guides and ?
These currently are defined in external units (no consideration of transforms, viewBox, etc.). Guides should be easy to auto adjust using the SVG scale (as defined above). Grids may be too (but I haven't tried yet).
Note: We will need to update grids and guides when we do the coordinate flip so if we do need a more sophisticated solution we can do it at the same time.
d. Use internally of 'unit identifiers'.
If absolute unit identifiers ('mm', 'in', 'pt', etc.) have been used internally (other than on the root SVG element), then these do need to be scaled to account for a switch between 90dpi and 96dpi. This is not a problem for pre-0.91 Inkscape created files. To keep it from being a problem in 0.91 Inkscape files, we need to disable saving 'font-size' with a 'pt' unit identifier.
Tav