Difference between revisions of "Units In Inkscape"

From Inkscape Wiki
Jump to navigation Jump to search
Line 72: Line 72:
 
A 2013 GSoC project by Matthew Petroff unified the Units handling in Inkscape, mostly implementing this philosophy. Inconsistencies should be viewed as bugs.
 
A 2013 GSoC project by Matthew Petroff unified the Units handling in Inkscape, mostly implementing this philosophy. Inconsistencies should be viewed as bugs.
  
= Use Scenarios =
+
= Page Size and Drawing Scale Changes =
  
 
How does/should Inkscape behave in various use scenarios?
 
How does/should Inkscape behave in various use scenarios?
  
== Cases ==
+
== Use Cases ==
  
* Pixel art <p>Should not be a problem. Everything is done in user units.</p>
+
; Pixel art
* A4/Letter size page. <p>Here the key is exporting to PDF. PDF follows postscript and uses 72 units per inch. Documents sized in terms of pixels need to be scaled properly (0.91 72/90, 0.92 72/96). This could be handled by an export option like is done for PNG export. Documents sized in terms of real units should not have a problem.</p>
+
: Every thing is done with 'user units'. No page size/scale to worry about.
* Scaled drawings. <p>Scaling determined by document size and viewBox. The current implementation does not handle arbitrary scaling well.</p>
+
; A4/Letter/etc. size page
 +
: The page size is defined by the SVG 'width'/'height' attributes. The main problem here is that pre-0.91 the page size is defined in terms of pixels with the assumption of 90dpi. A simple work-around is to set the 'width' and 'height' attributes to their desired values and add a 'viewBox' calculated at 90dpi. An alternative is to set an "export" dpi applicable to PDF/PostScript export like is done for PNG export.
 +
; Scaled drawings
 +
:Scaling determined by document size and viewBox. Need to add add GUI to handle this. There could be problems with handling scaling.
  
== Document Unit Changes ==
+
== Page Size/Scale Changes ==
  
* Resize page
+
* Page size is determined by SVG root 'width' and 'height'.
*# Grids/guides should not change.
+
* User unit is determined by 'viewBox'.
*# It might be useful to able to specify a guide at 50%.
+
* Document scale is determined by ratio of 'width'/'height' to 'viewBox'.
* Rescale page
 
** Change width/height but leave viewBox alone
 
** Change viewBox but leave width/height alone
 
* Change document units
 
*# Very messy and bug prone.
 
* Edit a 90dpi unit in 0.92 (96dpi)
 
* Edit a 96dpi unit in 0.91 (90dpi)
 
  
 +
Operations:
 +
 +
; Change page size
 +
: Change 'width'/'height' in GUI, 'viewBox' changed to keep scale. Grids/guides do not need any change.
 +
; Change 'user unit'
 +
: Change 'viewBox' via 'Scale factor'(?) in GUI. Grids/guides may need updating?
  
 
Notes:
 
Notes:
Line 100: Line 102:
 
# Guides are currently defined in external units, no unit identifier is allowed.
 
# Guides are currently defined in external units, no unit identifier is allowed.
 
# Grids are current defined in external units, a unit identifier is required.
 
# Grids are current defined in external units, a unit identifier is required.
 +
# Would be useful to allow guides to be defined in terms of %.
  
 
=Notes=
 
=Notes=
  
 
The outer SVG width/height, viewBox, and document-units should not be changed in the XML Editor. Use the Page tab of the Document Properties to change the document size or document unit to avoid the risk of them becoming inconsistent.
 
The outer SVG width/height, viewBox, and document-units should not be changed in the XML Editor. Use the Page tab of the Document Properties to change the document size or document unit to avoid the risk of them becoming inconsistent.

Revision as of 09:22, 1 December 2014

Introduction

This page documents the philosophy for Units handling inside Inkscape. Units are not as straight-forward as one should think they are.

Historical View

Part of the problem with units in SVG and CSS in general is why they are there in the first place. In the early days it was assumed that one would want to display drawings on a screen at full scale. In otherwords, a "one inch square" would be displayed on a screen as a physical one inch square. This required that displays be queryable as to what their true DPI was. Display manufactures rarely provided the means to query the DPI of the display, and when they did, they often returned incorrect results. Thus, the use of "real" units never became popular and in reality it is usually not what one wanted. Eventually, after long arguments, the CSS working group dictated that one inch would be fixed to 96 pixels regardless of screen resolution (ironically, with so called Retina displays, there is once again interest in scaling drawings based on DPI).

The Philosophy

Absolute units (other than 'px' inside CSS) should not be used inside an SVG file with one exception:

The root width and height may have units, which with a proper viewBox determines an appropriate scale for a drawing. (This sets the "real" world value of the SVG user unit.) This reflect the opinion of the majority of the SVG working group.

In CSS a unit identifier must be present. As 'px' is defined in SVG to be the same as a user unit the following are equal: font-size="20" and style="font-size:20px".

It should be noted that the relative units em, ex, and % can be useful in some cases.

Definitions

To better understand the following discussion it is necessary to have well defined terms to describe which unit is being talked about. Often unit is used when one should use unit identifier.

User Unit
A term defined by the SVG specification: a value in the current user coordinate system.
External Unit Identifier
The unit identifier in the root SVG width or height attribute. If the width is '10in', the External Unit Identifier is 'in'.
External Unit
A length of 1 as expressed with the External Unit Identifier. If the width is '10in', the External Unit is '1in'.
Internal Unit
The basic SVG unit. Never used with a unit identifier. It is the initial value of the User Unit. The real world value of the Internal Unit is determined by the 'SVG scale' determined from the root SVG width/height attributes and the viewBox.
GUI Unit Identifier ('inkscape:document-units')
The unit identifier displayed in the GUI. It should not be used when storing numerical values inside the SVG file (e.g. a width may be displayed in mm in the GUI but should be stored in user units). It is read in as SPNamedView->doc_units. This value is returned in 0.91 by getDefaultUnit() and in trunk by getDisplayUnit(). (Renamed to avoid confusion.)
During the run-up to 0.91 it was used in some places to represent the "SVG Scale".
Directly read in sp-namedview.cpp, read and written in ui/dialog/document-properties.cpp, metafile-inout.cpp, test_reassemble.c.
Page size units (namedview 'units')
Actually a Unit Identifier. Read in as SPNamedView->units.
Only used in ui/widget/page-sizer.cpp. It's only use is to set the default unit in the page-sizer widget. The variable has been renamed to 'page_size_units' in trunk.
SVG Scale
This is/will be a Geom::Scale variable that reflects the current scale factor between the SVG root 'width'/'height' and the 'viewBox'.

Inkscape & Units

Inkscape should not write out lengths with unit identifiers ('in', 'mm', etc.) other than in the root SVG element. Inkscape must, however, be able to interpret lengths with unit identifiers from non-Inkscape produced files according to the CSS defined value of 96 pixels (initial user-units) per inch.[1]

The use of unit identifiers in the Inkscape GUI is for ease of authoring only. The actual values should be stored as user-units.

The GUI should show values taking into account the GUI display unit identifier as well as the SVG scale calculated from the width/height and viewBox.

For example:

<svg width="100mm" height="100mm" viewBox="0 0 100 100">

describes a drawing 100mm x 100mm where one user-unit is equivalent to one "mm".

The SVG scale would be 1mm/1 user-unit.

If the GUI display unit ('inkscape:document-units') identifier is set to "mm" then the GUI would show a width of '25.4' for a rectangle 25.4 user-units wide. If the GUI display unit identifier is set to "in", the GUI would show '1.0'.

Note: In the run-up to 0.91 the Inkscape Document unit was sometimes used incorrectly to indicate the SVG scale resulting in a number of bugs.


A 2013 GSoC project by Matthew Petroff unified the Units handling in Inkscape, mostly implementing this philosophy. Inconsistencies should be viewed as bugs.

Page Size and Drawing Scale Changes

How does/should Inkscape behave in various use scenarios?

Use Cases

Pixel art
Every thing is done with 'user units'. No page size/scale to worry about.
A4/Letter/etc. size page
The page size is defined by the SVG 'width'/'height' attributes. The main problem here is that pre-0.91 the page size is defined in terms of pixels with the assumption of 90dpi. A simple work-around is to set the 'width' and 'height' attributes to their desired values and add a 'viewBox' calculated at 90dpi. An alternative is to set an "export" dpi applicable to PDF/PostScript export like is done for PNG export.
Scaled drawings
Scaling determined by document size and viewBox. Need to add add GUI to handle this. There could be problems with handling scaling.

Page Size/Scale Changes

  • Page size is determined by SVG root 'width' and 'height'.
  • User unit is determined by 'viewBox'.
  • Document scale is determined by ratio of 'width'/'height' to 'viewBox'.

Operations:

Change page size
Change 'width'/'height' in GUI, 'viewBox' changed to keep scale. Grids/guides do not need any change.
Change 'user unit'
Change 'viewBox' via 'Scale factor'(?) in GUI. Grids/guides may need updating?

Notes:

  1. Guides are currently defined in external units, no unit identifier is allowed.
  2. Grids are current defined in external units, a unit identifier is required.
  3. Would be useful to allow guides to be defined in terms of %.

Notes

The outer SVG width/height, viewBox, and document-units should not be changed in the XML Editor. Use the Page tab of the Document Properties to change the document size or document unit to avoid the risk of them becoming inconsistent.