Comment 11 for bug 1660228
Revision history for this message
| su_v (suv-lp) wrote Re: Clone of path in 0.91 doc has stroke that won't change thickness | #11 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
With Inkscape 0.92.0 r15299 (on OS X 10.7.5):
1) The core of the report - unexpected stroke-width attribute added to paths with unset stroke - reproduced when opening the legacy file with the option to 'Scale elements' (preserving the physical size). It is not added when using 'Set 'viewBox' (a different method to preserve the physical size), or with 'Ignore'.
2) The stroke width indicator in the status bar and in Fill&Stroke agree about the width of the stroke - the displayed units might differ depending on how the document was opened and what display units it uses (compared to the default template). IIRC there's a more specific report about this. Unrelated to 1)
3) Stroke width unexpected ("But they were 1.06666672 or something similar.") - that's a 1px stroke width in the original 90dpi-based document which was scaled according to the option for DPI change chosen by the user ('Scale elements'). This is in itself not a bug.
The issue exposed with the reporter's document is that an undefined stroke-width per SVG standard defaults to '1' ('px' aka SVG user unit), and if all elements in the drawing are scaled, so is the stroke-width (which requires to explicitly add the scaled value of the default width (the default on the other hand can be omitted [1]). Scaling the stroke width of paths does usually not have unintended side-effects - unless of course the path is cloned and the referencing <use> element(s) attempts to override the original's stroke width.
The result in this particular drawing is that all paths are visible reduced to the computed scaled width of the default value (1 -> 1.06666672) when opened with 'Scale elements', and the stroke-width defined per individual clone is no longer effective (because the parent's stroke-width is no longer 'undefined', and can't be overridden by the clone's own style).
Recommended solution for now would be to use "Set 'viewBox'" - it does not expose the reported issue, but equally preserves the physical size (by defining the document scale via viewBox attribute). If the physical size of the drawing does not matter, use 'Ignore' when prompted on open.
--
[1] https:/