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
- sounds interesting, thanks for describing this in such detail. - just one final question, because I am obsessive/compulsive. So which units would the actual coordinates of each object be expressed in? I am assuming the answer is "user Units" but I am not sure. From a practical point of view the problems that we have been encountering have not really been related to the concept of viewBox, but have actually been related to the messy mechanics of how to convert coordinates from one system to another system, and the fact that not all inkscape entities necessarily use the same units at present. So what would trigger such a conversion or recalculation? Would it be the re-definition of the "page scale" as opposed to the "page size"
Alvin
-- View this message in context: http://inkscape.13.x6.nabble.com/Units-rehash-tp4972318p4972322.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
On Wed, Dec 03, 2014 at 02:40:07PM +0100, Tavmjong Bah wrote:
Hi,
I have been living, breathing, and even dreaming units the past couple of weeks.
:-D
Thanks so much for staying focused on this. And thanks for setting up a wiki page for it.
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:
- 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.
Probably should define 'user units' here, and maybe even give examples of what you mean by 'real world units'.
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.
The svgUnit mention is kind of non-sequitor here... I've not been following developments on units so it may be common knowledge but for future reference it might help to say where the svgUnit (proposal? change?) comes from and was intended to do.
- 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.
So this is literally just switching from e.g. 8.5x11 to 8.5x14 paper size, and your drawing remains unchanged, just the page gets longer?
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 donewith 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.
Gotcha. So with page scale, the units are literally the physical dimensions of the printed out page. And if I understand right, it would be very rare for a user to need to tinker with these settings?
There's one more that fits nicely here:
* Change dimensioning scale:
Drawings of real world physical things (e.g. a map or technical drawing) are created in terms of real world physical units (meters, miles, nanometers, etc.) The dimensioning scale allows for representing a 10 foot pole by a thin but proportionately correct rectangle on an 8.5x11" page. By keeping everything properly scaled, an engineer could use a ruler to measure elements from the page, multiply the measurement by the dimensioning scale, and know what the corresponding real world physical length should be.
The dimensioning scale is defined in terms of 'user units', (e.g. '5 km == 1 user unit'). Combining this with the page scale, we communicate to the user a 'page dimensioning scale' (e.g. '5 km to 1 mm'). The GUI should present a widget for selecting or entering the 'page dimensioning scale'. If the selected dimensioning scale replaces a previously specified dimensioning scale (i.e. it wasn't set to 1:1), then the drawing elements are scaled accordingly. (E.g. you start up Inkscape and draw a town map without considering the scale, then set it after the fact changing it from 1":1" to 1 mile per inch; no scaling takes place. Later you're asked to include the outskirts of town, so you set the scale factor to 2 miles per inch, and your existing drawn streets and buildings shrunk by half.)
When it's set, the dimensioning scale can control the units shown in the GUI, the position and spacing of the grid and guides, and the formatting of labels in the document (such as printed measurements, dimensioning arrows, etc.)
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 theduplicate 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.
Sounds like some unit unit test writing should be high on the todo list for 0.92. Do we have any test cases yet for guides and grids?
Bryce
On Wed, 2014-12-03 at 13:04 -0800, Bryce Harrington wrote:
On Wed, Dec 03, 2014 at 02:40:07PM +0100, Tavmjong Bah wrote:
Hi,
I have been living, breathing, and even dreaming units the past couple of weeks.
:-D
Thanks so much for staying focused on this. And thanks for setting up a wiki page for it.
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:
- 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.
Probably should define 'user units' here, and maybe even give examples of what you mean by 'real world units'.
I've updated the Wiki page to respond to most of you comments.
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.
The svgUnit mention is kind of non-sequitor here... I've not been following developments on units so it may be common knowledge but for future reference it might help to say where the svgUnit (proposal? change?) comes from and was intended to do.
Johan proposed adding the 'svgUnit' which would be Inkscape's best guess at what the real world value of the 'user unit'. So if the width attribute has a value of 100mm and the 'viewBox' says the document is 100 'user units' wide, the svgUnit would be a 'mm'. I feel this is not necessary and in fact less than optimal as it doesn't handle cases where the 'user unit' is different in x and y (which is allowed in SVG and which is handled perfectly fine by Inkscape).
- 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.
So this is literally just switching from e.g. 8.5x11 to 8.5x14 paper size, and your drawing remains unchanged, just the page gets longer?
Exactly, just as Inkscape already does (with the exception it sometimes adds an unnecessary transform to account for the fact that Inkscape's y coordinate is upside down).
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 donewith 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.
Gotcha. So with page scale, the units are literally the physical dimensions of the printed out page. And if I understand right, it would be very rare for a user to need to tinker with these settings?
Only if the user wants to change to a different size paper.
There's one more that fits nicely here:
Change dimensioning scale:
Drawings of real world physical things (e.g. a map or technical
drawing) are created in terms of real world physical units (meters, miles, nanometers, etc.) The dimensioning scale allows for representing a 10 foot pole by a thin but proportionately correct rectangle on an 8.5x11" page. By keeping everything properly scaled, an engineer could use a ruler to measure elements from the page, multiply the measurement by the dimensioning scale, and know what the corresponding real world physical length should be.
The dimensioning scale is defined in terms of 'user units',(e.g. '5 km == 1 user unit'). Combining this with the page scale, we communicate to the user a 'page dimensioning scale' (e.g. '5 km to 1 mm'). The GUI should present a widget for selecting or entering the 'page dimensioning scale'. If the selected dimensioning scale replaces a previously specified dimensioning scale (i.e. it wasn't set to 1:1), then the drawing elements are scaled accordingly. (E.g. you start up Inkscape and draw a town map without considering the scale, then set it after the fact changing it from 1":1" to 1 mile per inch; no scaling takes place. Later you're asked to include the outskirts of town, so you set the scale factor to 2 miles per inch, and your existing drawn streets and buildings shrunk by half.)
When it's set, the dimensioning scale can control the units shown inthe GUI, the position and spacing of the grid and guides, and the formatting of labels in the document (such as printed measurements, dimensioning arrows, etc.)
That seems like a reasonable extension. BTW, we already support the non-standard 'm' and 'ft' unit identifiers in the GUI (the page size is actually written out as 'cm' and 'in' respectively).
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 theduplicate 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.
Sounds like some unit unit test writing should be high on the todo list for 0.92. Do we have any test cases yet for guides and grids?
There is a page of test cases. The link is at the end of the above mentioned page. I need to add some test for the 3D box tool.
Tav
2014-12-03 14:40 GMT+01:00 Tavmjong Bah <tavmjong@...8...>:
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:
- 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.
Note from me:
My understanding is that SVG root width / height is different from all the other unit-bearing lengths in the document. For example, when a rect is defined with height equal to 10mm, it is converted to the relevant number of user units, using the fixed ratio of 96 user units per inch. However the SVG root width / height specify the actual physical dimensions of the image, so if display resolution information is available (e.g. from EDID), the image should be displayed in the specified physical size.
In other words an image that has height="1in" and width="1in" on the SVG root is not guaranteed to always take up 96x96 pixels - the user agent should figure out the resolution of the display, and on a 150dpi display the image should be 150x150 pixels.
Regards, Krzysztof
On Thu, 2014-12-04 at 15:40 +0100, Krzysztof Kosiński wrote:
2014-12-03 14:40 GMT+01:00 Tavmjong Bah <tavmjong@...8...>:
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:
- 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.
Note from me:
My understanding is that SVG root width / height is different from all the other unit-bearing lengths in the document. For example, when a rect is defined with height equal to 10mm, it is converted to the relevant number of user units, using the fixed ratio of 96 user units per inch. However the SVG root width / height specify the actual physical dimensions of the image, so if display resolution information is available (e.g. from EDID), the image should be displayed in the specified physical size.
In other words an image that has height="1in" and width="1in" on the SVG root is not guaranteed to always take up 96x96 pixels - the user agent should figure out the resolution of the display, and on a 150dpi display the image should be 150x150 pixels.
Correct (and a rectangle with a width of 96px would be shown on the display with a width of 150 display pixels).
It is unfortunate that inside an SVG file the unit-identifier of 'px' was chosen to represent on 'user unit'. A 'pixel' inside an SVG file is ->not<- the same as a screen pixel except in the case where the 'viewBox' width and height match the SVG width and height measured in 'px' (or in the case where there is no 'viewBox') and where the SVG is being displayed with it's nominal width and height.
Tav
Regards, Krzysztof
On Thu, 04 Dec 2014 16:11:45 +0100 Tavmjong Bah <tavmjong@...8...> wrote:
On Thu, 2014-12-04 at 15:40 +0100, Krzysztof Kosiński wrote:
2014-12-03 14:40 GMT+01:00 Tavmjong Bah <tavmjong@...8...>:
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:
- 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.
Note from me:
I have a simple request. I almost always work in inches. The scales at the top and on the left side measure to a quarter of an inch. I would like them to have 1/8 inch markings also when the total image is zoomed in on. The new "ruler" is helpful but a bit awkward to work with.
Tavmjong Bah wrote
On Thu, 2014-12-04 at 15:40 +0100, Krzysztof Kosiński wrote:
My understanding is that SVG root width / height is different from all the other unit-bearing lengths in the document. For example, when a rect is defined with height equal to 10mm, it is converted to the relevant number of user units, using the fixed ratio of 96 user units per inch.
Correct
Well, that was not entirely correct...
When a rect is defined to be '10 mm' by the user input, it's not "converted to the relevant number of user units, using the fixed ratio of 96 user units per inch". This may happen only if the ratio between the viewbox and the page size happens to be 96. Instead, it's converted to some number of user units which, considering the page size and the viewbox ratio, do correspond to 10 mm.
The counter-calculation (from the user unit to the real world unit) must always pass through the page size and the viewbox ratio which is not fixed anymore.
Am I wrong?
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Units-rehash-tp4972318p4972333.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
Hi Krzysztof, the main point about units is not drawing on screen but storing numbers inside the SVG document. The drawing engine should first understand what to draw when it founds a 100x150 rect (100 what? 150 what?): if the page is 210 mm x 297 mm and the viewbox is (0, 0, 2100, 2970) this means that '1x1' (user unit) corresponds to '0.1 mm x 0.1 mm' (real world unit) hence the rect is intended to be 10 mm x 15 mm. Only after this is solved (and the unit discussion is related to what happens up to here and no further) the drawing engine can start making its own calculations based on the output DPI (if it's known, otherwise the 96 DPI default is used) and on the actual zoom level to find out how many pixels the rect will be, but this is another story.
Luca
-- View this message in context: http://inkscape.13.x6.nabble.com/Units-rehash-tp4972318p4972330.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.
participants (6)
-
alvinpenner -
Bryce Harrington -
John Culleton -
Krzysztof Kosiński -
LucaDC -
Tavmjong Bah