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?

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

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