Difference between revisions of "Units In Inkscape: Document Unit Change"
(Created page with " See also: Units in Inkscape The ''Document Unit'' can be changed from the ''Document Properties'' '''Page''' tab under "General: Deafult Units". Changing the Document Un...")
m (→Failings: fix bug link)
|Line 26:||Line 26:|
* [https://bugs.launchpad.net/inkscape/+bug/1279534 ]
* ADD MORE BUGS
* ADD MORE BUGS
Revision as of 14:20, 21 September 2014
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.
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').
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?
- 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.
- SPNamedView (Does this really belong under SPObjectGroup?)
* Has 'viewBox'. # Is container.