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
On 25-Nov-2014 03:46, Tavmjong Bah wrote:
- % 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).
If you would like to weigh in, there is an open bug concerning that second case here:
https://bugs.launchpad.net/inkscape/+bug/1245989
where at least in some versions (I have not checked lately) it was opening these files as an unusable 1x1 px image.
- Precision
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.
IEEE 754 specifies 6-9 digit text representations, see page 4
http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
The meaning of that range is specifically that for a conforming implementation, when numbers are converted textA -> internal 32bit float -> textB, then textA must be identical to textB.
Is the numerical precision you are referring to just for the GUI or does it also include values written to the SVG file? Is it total displayed digits or just digits after the decimal point?
In any case, MAX_PRECISION (or whatever it is called in Inkscape) needs to be set by the underlying float type. Going to double precision for internal calculations is fine but if the SVG specifies that values must be 32 bit floats then the corresponding fields in the objects should be as well. So maybe 9, but definitely not 16. Otherwise we will run into situations where a file will look one way in Inkscape, then save, reopen, will look slightly different, due to the loss of precision on conversion for the save. It might be a tiny difference, but it still shouldn't happen. One reason to insist on perfect "round trip" performance is that it greatly simplifies testing - just use "diff" on the input and output and if they are the same the test is passed. If tiny changes in precision are allowed then determining "pass" in such a test often becomes incredibly messy.
- 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.
As in it currently fails with clipping, patterns, and anything that refers to something stored in <defs>. There are several related bugs about this, here is one:
https://bugs.launchpad.net/inkscape/+bug/1348417
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" ...>
Sounds like the simplest solution.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech
In order to release 0.91, I tried to fix the most pressing issues with units. (and committed the work to trunk for testing)
On 25-11-2014 12:46, Tavmjong Bah wrote:
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.
'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.)
'svg_units'
...
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.
This is what 'svg-units' is supposed to mean. "0.5 mm". Currently, this is not supported. If the scale factor cannot be found in the unit table, a special "user unit" should be added to the unit table / updated with the "0.5 mm" factor. That then becomes the "svg_units". Similarly in inkey.py where we also try to derive the "svg units" from width&viewbox.
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.)
My focus is to release 0.91, where I think we should just skip this aspect of SVG's capabilities.
- % 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:
I chose to ignore the possibility of percentages. So units will probably not work very well with such (awkward) documents. I believe it is correct to do something random in such cases anyway. As you write, the percentages mean to fill the space available. This space can be anything, so any arbitrary scaling can be applied to X and Y and no-one can tell you you are wrong. :) So Inkscape now probably does something random with units, and it is all standard compliant ;-)
- 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'.
Indeed, I was surprised at this when fixing a unit-test bug. +1 for simply changing the internals to type double.
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.
- 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" ...>
I think in 0.91.1, we should automatically add a viewbox when none is present (using 90 dpi). I believe this will solve many potential forward compatibility issues. If in trunk we then implement the "0.5 mm" user unit thing (see above), opening 0.91 document in 0.92 should pretty much work (I think?).
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.)
Absolute page size, perhaps. But being able to specify the dimensions of an object in units that are not going to change depending on the viewer is very useful too. As you say, viewbox takes care of this. No extra stuff needed. When there is no viewbox present, we can automatically add one but first ask the user what DPI he wants to use (could be arbitrary value really).
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.
There is a branch (not ready for merging) that fixes up grids and guides to use proper SVG units like the rest of the SVG document.
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.
So then please disable that!
-Johan
On Tue, Nov 25, 2014 at 11:15 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 25-11-2014 12:46, Tavmjong Bah wrote:
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.
So then please disable that!
I commented out the widget for the preference in trunk to allow writing non-px units to the file. I will backport it as well (probably in the units patch).
Cheers, Josh
On Tue, 2014-11-25 at 12:33 -0800, Josh Andler wrote:
On Tue, Nov 25, 2014 at 11:15 AM, Johan Engelen <jbc.engelen@...2592...> wrote:
On 25-11-2014 12:46, Tavmjong Bah wrote:
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.
So then please disable that!
I commented out the widget for the preference in trunk to allow writing non-px units to the file. I will backport it as well (probably in the units patch).
Excellent!
As part of a unit patch, please replace the share/ui/units.xml file with the one attached (which is specifically crafted for 0.91 using 90dpi). It increases the precision of the conversion constants as well as fixed an incorrect degree to gradian conversion factor.
Tav
On Tue, 2014-11-25 at 20:15 +0100, Johan Engelen wrote:
In order to release 0.91, I tried to fix the most pressing issues with units. (and committed the work to trunk for testing)
Absolutely correct to focus on 0.91.
On 25-11-2014 12:46, Tavmjong Bah wrote:
'svg_units'
...
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.
This is what 'svg-units' is supposed to mean. "0.5 mm". Currently, this is not supported. If the scale factor cannot be found in the unit table, a special "user unit" should be added to the unit table / updated with the "0.5 mm" factor. That then becomes the "svg_units". Similarly in inkey.py where we also try to derive the "svg units" from width&viewbox.
This sound more complicated that simply using a scaling factor. We don't need to add anything to the unit table.
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.)
My focus is to release 0.91, where I think we should just skip this aspect of SVG's capabilities.
Agreed, for 0.91. For 0.92, I really think an 'svg-scale' is the way to go.
- % 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:
I chose to ignore the possibility of percentages. So units will probably not work very well with such (awkward) documents. I believe it is correct to do something random in such cases anyway. As you write, the percentages mean to fill the space available. This space can be anything, so any arbitrary scaling can be applied to X and Y and no-one can tell you you are wrong. :) So Inkscape now probably does something random with units, and it is all standard compliant ;-)
In #1245989 I've commented on what should be done. Again, I would not worry about this for 0.91.
- 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'.
Indeed, I was surprised at this when fixing a unit-test bug. +1 for simply changing the internals to type double.
This might be a quite invasive change so I would leave it till 0.92.
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.
- 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" ...>
I think in 0.91.1, we should automatically add a viewbox when none is present (using 90 dpi). I believe this will solve many potential forward compatibility issues.
Good idea.
If in trunk we then implement the "0.5 mm" user unit thing (see above), opening 0.91 document in 0.92 should pretty much work (I think?).
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.)
Absolute page size, perhaps. But being able to specify the dimensions of an object in units that are not going to change depending on the viewer is very useful too. As you say, viewbox takes care of this. No extra stuff needed. When there is no viewbox present, we can automatically add one but first ask the user what DPI he wants to use (could be arbitrary value really).
Should work.
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.
There is a branch (not ready for merging) that fixes up grids and guides to use proper SVG units like the rest of the SVG document.
I am not sure this is really necessary. Just as we shouldn't normally use unit identifiers inside an SVG, we should not use them for grids/guides. But again, a post 0.91.0 item.
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.
So then please disable that!
Josh seems to be on this!
Tav
On 26-11-2014 14:39, Tavmjong Bah wrote:
On Tue, 2014-11-25 at 20:15 +0100, Johan Engelen wrote:
In order to release 0.91, I tried to fix the most pressing issues with units. (and committed the work to trunk for testing)
Absolutely correct to focus on 0.91.
On 25-11-2014 12:46, Tavmjong Bah wrote:
'svg_units'
... 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.
This is what 'svg-units' is supposed to mean. "0.5 mm". Currently, this is not supported. If the scale factor cannot be found in the unit table, a special "user unit" should be added to the unit table / updated with the "0.5 mm" factor. That then becomes the "svg_units". Similarly in inkey.py where we also try to derive the "svg units" from width&viewbox.
This sound more complicated that simply using a scaling factor. We don't need to add anything to the unit table.
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.)
My focus is to release 0.91, where I think we should just skip this aspect of SVG's capabilities.
Agreed, for 0.91. For 0.92, I really think an 'svg-scale' is the way to go.
The units table is actually an "SVG scale". It just puts a name on some of the common scaling factors. :-)
- % 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:
I chose to ignore the possibility of percentages. So units will probably not work very well with such (awkward) documents. I believe it is correct to do something random in such cases anyway. As you write, the percentages mean to fill the space available. This space can be anything, so any arbitrary scaling can be applied to X and Y and no-one can tell you you are wrong. :) So Inkscape now probably does something random with units, and it is all standard compliant ;-)
In #1245989 I've commented on what should be done. Again, I would not worry about this for 0.91.
- 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'.
Indeed, I was surprised at this when fixing a unit-test bug. +1 for simply changing the internals to type double.
This might be a quite invasive change so I would leave it till 0.92.
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.
- 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" ...>
I think in 0.91.1, we should automatically add a viewbox when none is present (using 90 dpi). I believe this will solve many potential forward compatibility issues.
Good idea.
If in trunk we then implement the "0.5 mm" user unit thing (see above), opening 0.91 document in 0.92 should pretty much work (I think?).
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.)
Absolute page size, perhaps. But being able to specify the dimensions of an object in units that are not going to change depending on the viewer is very useful too. As you say, viewbox takes care of this. No extra stuff needed. When there is no viewbox present, we can automatically add one but first ask the user what DPI he wants to use (could be arbitrary value really).
Should work.
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.
There is a branch (not ready for merging) that fixes up grids and guides to use proper SVG units like the rest of the SVG document.
I am not sure this is really necessary. Just as we shouldn't normally use unit identifiers inside an SVG, we should not use them for grids/guides. But again, a post 0.91.0 item.
What I mean is: grids and guides defined in document coordinates. Not with units attached, because indeed that is not needed and probably harmful. Right now, the coordinate values themselves are broken and hinder progress.
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.
So then please disable that!
Josh seems to be on this!
Tav
participants (4)
-
Johan Engelen -
Josh Andler -
mathog -
Tavmjong Bah