Units In Inkscape: Document Unit Change

See also: Units In Inkscape

The Document Unit can be changed from the Document Properties Page tab under "General: Default Units". Changing the Document Unit changes the relationship between the width/height and viewBox such that the initial user unit (aka 'px') is equal to the Document Unit.

In order to make this change, Inkscape walks through the document changing all length units it finds (or attempt to). This has led to many bugs.

Question: Do we want to disable changing Document Unit in 0.91 (until all the bugs are worked out)?

Question: Can we better describe what is happening when a user changes the Document Unit. It is not clear that there is an invasive change happening inside the file (unlike changing the units for the 'Page Size' which alters just the outer 'width' and 'height').

Question: How is an externally generated SVG without an inkscape:document unit handled?

Notes:

1. This is not the same as changing the GUI units which only effects what is displayed (you set a width to 1 inch but if the document unit is 'px' the value in the SVG file is 90px or 96px).
2. This is independent of the change from 90 pixels to one inch to the SVG/CSS value of 96 pixels per inch.

Implementation

Changing "General: Default Units" calls:

document_properties.cpp: DocumentProperties::onDocUnitChange()

This function sets transforms of stroke, rect corners, pattern, gradient to true. (Should filters also be transformed?) And then calls

sp-item-group: SPGroup::scaleChildItemsRec()

on the root element. Which recursively goes through all groups in the document, making the required scale change.

Note that SPGroup::scaleChildItemsRec() is also used in metafile-inout.cpp

Question: Should scaleChildItemsRec really be a member function of SPGroup?

Failings

Bugs:

• Bug 1279534: text-on-path size changes if you change default document units
• Bug 1278561: flowed text appearance changes depending on default document units
• Bug 1332043: Text moved just after creation is moved off document to canvas

• Bug 1239682: Rounded rect Rx and Ry fields wrong
• Bug 1247801: Stroke width not correctly remembered with mm as unit
• Bug 1248120: Text toolbar spinboxes are not really useful with default units changed
• Bug 1279568: not all stroked objects have same default stroke width if default document units are not px
• Bug 1287288: clip-path of clipped group incorrectly scaled when changing default units (rev >= 12554)
• Bug 1310787: resize page to drawing resets unit to px (rev >= 12554)
• Bug 1354339: Changing the default unit scales paths with Pattern along the path LPE applied
• Bug 1363453: Undo of a change in document units causes nodes to move while object stays unchanged.
• Bug 1365451: Symbols scales wrong when document unit is not px (rev >= 12554)
• Bug 1369197: translations of groups are not converted to new units when changing document units
• Bug 1373311: Guides positions not stored in user unit
• ADD MORE BUGS

Problems:

• Scaling should but does not occur in SPDefs, SPClipPath, SPMask, SPImage, SPGlyph? as these are not derived from SPGroup.
• Scaling applies a transform to child elements.
  • This naive scaling does not always work, as the case of SPNamedView (grids and guidelines are not updated) or SPUse (where the 'x' and 'y' values are not scaled).
  • For text on a path, the scaling is applied twice, once on the path and once on the text.
  • It also introduces unwanted structural changes, introducing or removing the 'transform' property depending on the value of the "Store Transform" preference value ('Optimized' or 'Preserved').
• For elements with a 'viewBox' it is not clear what should happen:
  • Should markers be scaled? How does this interact with 'stroke-width'? What about the 'refX' and 'refY' values?
  • Should symbols be scaled? Probably not, as the same symbol added from an external library will be different depending on when it was added (before or after a unit change). (Same might be true for markers.)
• How are style properties handled? 'transform', 'x', and 'y' are being turned into properties from attributes.
• How are elements that define their coordinate space via 'userSpaceOnUse' or 'boundingBox' handled?

Current Object Hierarchy

This hierarchy is useful to trace what is effected by SPGroup::scaleChildItemsRec(), etc.

• Object
  • SPDefs^#
  • SPDesc
  • SPFilterPrimitive
  • SPFilter
  • SPFlowline
  • SPFlowregionbreak
  • SPFontFace
  • SPFont
  • SPGlyphKerning
  • SPGlyph
  • SPGuide
  • SPItem
    • SPFlowdiv
    • SPFlowtpsan
    • SPFlowpara
    • SPFlowregion
    • SPFlowregionexclude
    • SPFlowtext
    • SPImage^*#
    • SPLPEItem
      • SPGroup
        • SPBox3D
        • SPMarker^*
        • SPAnchor
        • SPRoot^*
        • SPSwitch
        • SPSymbol^*#
      • SPShape
        • SPGenericEllipse
        • SPLine
        • SPOffset
        • SPPath
        • SPPolygon
        • SPPolyline
        • SPRect
        • SPSpiral
    • SPText
    • SPTextPath
    • SPTRef
    • SPTSpan
    • SPUse
  • SPMeshPatch
  • SPMeshRow
  • SPMetadata
  • SPMissingGlyph
  • SPObjectGroup
    • SPClipPath^#
    • SPMask^#
    • SPNamedView (Does this really belong under SPObjectGroup?)
  • SPPaintServer
    • SPGradient
      • SPLinearGradient
      • SPMeshGradient
      • SPRadialGradient
    • SPPattern^*#
    • SPSolidColor
  • SPScript
  • SPStop
  • SPString
  • SPStyleElem
  • SPTagUse
  • SPTag
  • SPTitle

^* Has 'viewBox'. ^# Is container.