'Scale elements': Clone of path in 0.91 doc has stroke that won't change thickness

[Will Pittenger]

When I import https://1drv.ms/u/s!An39hJGl5zAVijaIu2q00wNifh0G (a file created by 0.91) into 0.92, the strokes on the paths don't change. (For reference, the paths in question are the those used for the track. They're also clones of the actual path.) I zoomed in and found the stroke was actually changing, but not enough to account for the amount I was trying to changing the stroke by. I'm sorry I can't simplify the original file. I don't have 0.91 anymore.

I created a new clone of one of the paths. Same issue. I created a new document and tried to create the issue with a rectangle there. No luck. It appears to be something to do with the import process.

I also noted the stroke thickness reported on the statusbar didn't match the thickness in the Fill & Stroke dialog.

After poking around, I found the original, which shouldn't have had a stroke, does. Deleting that stroke seems to resolve the problem. I checked the original document's source using Notepad++. Unlike the version imported by 0.92, the original doesn't have strokes set on the path. Why would the import process put a stroke there?

Finally, the stroke it picked was totally different from what it should have been. Most of the path clones for the track in black or grey should have a stroke width of 5px. But they were 1.06666672 or something similar. That was both regardless of the "Scale stroke" preference setting.

[Will Pittenger (will-pittenger1)]

Oh, I noticed the inkscape:export-xdpi and inkscape:export-ydpi attributes were still set to 90 rather than 96. Changing that had no effect, but that did seem to be a bug too.

[su_v (suv-lp)]

Attaching the original SVG file from the external link to the bug report - links tend to disappear over time or might get replaced with newer versions (content changed).

[su_v (suv-lp)]

Note (for triage):

1) The original file was last edited with inkscape:version="0.47 r22583" (not Inkscape 0.91), and does not use a viewBox to define the document scale. Document width and height are defined (unit-less) as width="1418.974" height="716.26862" (i.e. in user units based on 90dpi).

2) Importing such a legacy file does not trigger the dpi-change dialog (unlike open).

3) Ungrouping the group resulting from 'File > Import' in Inkscape 0.92 may result in unexpected changes wrt stroke widths of the visible paths (actually clones) if the new document uses a different document scale (e.g. based on the default template with user units matching mm). This could be among the root causes for the reported issue(s).
The stroke width is not changed on ungroup when imported into a new document which is based on px (e.g. 'File > New from Template > Generic canvas').

4) I have not been able to reproduce that an unexpected stroke-width property is being added to the original paths which are referenced by (filtered) clones.

[su_v (suv-lp)]

Note (for triage): cont.

5) The file 'Stroke thickness bug demo.svg', last edited with Inkscape 0.92.0 r15299, seems to be either based on a custom user template or is also a legacy file which originated from an older version before Inkscape 0.91 (it lacks the viewBox attribute, and defines width="88.153748", height="140.16411" (thus based on 96dpi, since this is Inkscape 0.92)).

Will Pittenger wrote:
> I also noted the stroke thickness reported on the statusbar didn't
> match the thickness in the Fill & Stroke dialog.

Make sure that both use the same units - the one in the status bar has a unit selector in the context menu (it defaults to 'mm', unfortunately, if the file is loaded into an empty document window, whereas your documents use 'px' as display units).

[Will Pittenger (will-pittenger1)]

The demo SVG is a simplified version of the original. Just the two paths and everything else stripped out.

[Will Pittenger (will-pittenger1)]

And, yes, I should have said "imported from an older version of Inkscape" rather than "imported from 0.91."

[su_v (suv-lp)]

Will Pittenger wrote:
> The demo SVG is a simplified version of the original.

If the report is not about importing (via 'File > Import') a legacy file into an existing or new one - could you please add details about which option you chose/choose when opening (via 'File > Open') the original legacy file directly in Inkscape 0.92 (when prompted with "Old Inkscape file detected (90dpi)")?

[Will Pittenger (will-pittenger1)]

I used File/Open rather than File/Import. The dialog you mentioned did pop up. I choose "Scale Elements."

[su_v (suv-lp)]

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://www.w3.org/TR/SVG11/painting.html#StrokeWidthProperty

[su_v (suv-lp)]

Confirming for now.

--
I'm not sure though there's an easy solution to address this specific use case.

[Will Pittenger (will-pittenger1)]

I should note in the original document, the physical dimension was never a concern. All I cared about was the pixel size.