Interpolate extension fails if end path has no 'stroke-width' attribute (0.91, 0.92)

Bug #1654743 reported by su_v on 2017-01-07
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Inkscape
Medium
su_v
0.92.x
Medium
su_v

Bug Description

Interpolating style with 'Extensions > Generate from path > Interpolate' fails if the end path has no 'stroke-width' property defined (this style property is for example (correctly) removed when the stoke style set to 'Unset' (the '?' button) in the Fill and Stroke dialog).

The error reproduces with Inkscape >= 0.91 (older versions do not fail).

Steps to reproduce:
1) launch inkscape (0.91 or 0.92)
2) open attached file (choose 'Ignore' for dpi change in 0.92)
3) select all (Ctrl+A)
4) open 'Extensions > Generate from path > Interpolate'
5) check '[x] Interpolate style'
6) uncheck '[ ] Use Z-order' (if checked, 0.92 only)
7) click 'Live preview' or 'Apply'

Note (off-topic): without relying on the Z-order of the selected objects, the extension will reverse the selection order each time live-preview is toggled off and on again, which can cause the impression that the reported issue does not reproduce (when with switched order the end path is the one with the stroke-width defined).

Traceback with attached file using Inkscape 0.91:

Traceback (most recent call last):
  File "interp.py", line 320, in <module>
    e.affect()
  File "/Users/su_v/TEMP/inkscape-dist/inkscape-0.91/inst/share/inkscape/extensions/inkex.py", line 268, in affect
    self.effect()
  File "interp.py", line 143, in effect
    basestyle['stroke-width'] = self.tweenstyleunit('stroke-width',sst,est,0)
  File "interp.py", line 109, in tweenstyleunit
    ep = self.unittouu(end[property])
KeyError: 'stroke-width'

Likely related to the changes in rev 13030:
https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13030

https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/13030/share/extensions/interp.py#share/extensions/interp.py

Reproduced with Inkscape 0.91 r13725 and Inkscape 0.92 r15299 on OS X 10.7.5.

=====
Originally reported on the user mailing list:
https://sourceforge.net/p/inkscape/mailman/message/35589734/

Related branches

su_v (suv-lp) on 2017-01-07
description: updated
description: updated
su_v (suv-lp) wrote :

Attaching proposal (minimal diff) to provide fallback value for 'stroke-width' ("1px") [1].

---
[1] https://www.w3.org/TR/SVG11/painting.html#StrokeWidthProperty

jazzynico (jazzynico) wrote :

Bug reproduced on Xubuntu 16.04, lp:inskcape/0.92.x rev. 15309.
Patch tested successfully on the same machine.

Targeting to 0.93, but since there's no risk of regression here (just setting a default value replace a missing one), it could be backported to 0.92.1.

Changed in inkscape:
assignee: nobody → su_v (suv-lp)
importance: Undecided → Medium
milestone: none → 0.93
status: New → In Progress
tags: added: backport-proposed
jazzynico (jazzynico) wrote :

Fixed in lp:inkscape rev. 15401.

Changed in inkscape:
status: In Progress → Fix Committed
Brynn (brynn4inks) wrote :

Thanks suv and jazzynico!

You are wizards!

Brynn (brynn4inks) wrote :

Hhmm, based on my limited technical understanding, I thought if I added strokes to my objects (or at least one of them, I might avoid this. But not so much.

Now both objects have strokes (1px width), but I still get a traceback, with no results.

Traceback (most recent call last):
  File "interp.py", line 333, in <module>
    e.affect()
  File "C:\Program Files\Inkscape\share\extensions\inkex.py", line 283, in affect
    self.effect()
  File "interp.py", line 156, in effect
    basestyle['stroke-width'] = self.tweenstyleunit('stroke-width',sst,est,0)
  File "interp.py", line 114, in tweenstyleunit
    ep = self.unittouu(end[property]) / scale
KeyError: 'stroke-width'

Any files you need, just let me know :-)

su_v (suv-lp) wrote :

@Brynn - the SVG fallback value for undefined stroke-width is '1px' - we'd certainly need a test case (Inkscape SVG) to determine whether the (default) property is explicitly defined in the source or not.

My guess is that your second example triggers the same bug because Inkscape uses the fallback value of 1px to render the stroke (and to display information about the stroke width to users in the GUI).

Brynn (brynn4inks) wrote :

I'm not sure what you mean. I thought it might not be the same bug, because the traceback is slightly different.

But if it's the same, do you mean that making the stroke width 1.1 px or larger, would avoid the bug?

Oh yeah, that makes it work!

Uh-oh....at first I attached a test file for you, where it still doesn't work with a 1 px stroke. But now that a wider stroke solves the problem, I don't personally need a fix. But I don't see any way to unattach the file.

Oh well, there it is, if you need it. Otherwise, I'm happy with this workaround.

Thanks again :-)

su_v (suv-lp) wrote :

The file 'interp-error.svg' from comment 8 is affected by the same underlying issue as originally reported: the tiny path in the bottom-left corner (id="path106181") does not have an explicit 'stroke-width' style property defined:

    <path
       style="fill:#b3b3b3;fill-opacity:1;stroke:#b3b3b3;stroke-opacity:1"
       d="m 64.05585,1041.3622 a 1,1 0 0 1 -1,1 1,1 0 0 1 -1,-1 1,1 0 0 1 1,-1 1,1 0 0 1 1,1 z"
       id="path106181"
       inkscape:connector-curvature="0" />

and renders with 1px default stroke width in Inkscape and other SVG viewers using the initial value ('1') as defined in the SVG specification. The extension script in Inkscape 0.91 and 0.92 did not account for such cases. The fix committed to trunk and tagged for backporting to the stable release branch 0.92.x will also address the use case as demonstrated in the file from comment 8.

jazzynico (jazzynico) wrote :

Backport accepted (IRC).

jazzynico (jazzynico) wrote :

Backported to lp:inkscape/0.92.x rev. 15312.

Changed in inkscape:
milestone: 0.93 → 0.92.1
Bryce Harrington (bryce) on 2017-01-13
Changed in inkscape:
milestone: 0.92.1 → 0.93
jazzynico (jazzynico) on 2017-01-21
tags: removed: backport-proposed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers