Difference between revisions of "Units In Inkscape: Document Unit Change"

From Inkscape Wiki
Jump to navigation Jump to search
 
Line 2: Line 2:
See also: [[Units In Inkscape]]
See also: [[Units In Inkscape]]


The ''Document Unit'' can be changed from the ''Document Properties'' '''Page''' tab under "General: Deafult 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.
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.
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.
Line 9: Line 9:


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: 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:
# 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).
# This is independent of the change from 90 pixels to one inch to the SVG/CSS value of 96 pixels per inch.


=Implementation=
=Implementation=

Latest revision as of 08:15, 18 November 2014

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:


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.