Pattern along Path broken in 0.91, both on-canvas and on pdf/png export
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Fix Released
|
High
|
Alvin Penner |
Bug Description
pattern-along-path (the path effect, not the equivalently named extension) is broken in 0.91. This regression first occurs in 0.9x, in 0.48, pattern-along-path was rendering correctly.
Exported PNG image of the broken behaviour:
https:/
Exported PDF of the broken behaviour:
https:/
SVG file that exposes the broken behaviour:
https:/
There are a variety of different control point configurations in which the erroneous rendering occurs, it appears to me that it happens most of the time when AB (the line between the first node and its handle) and CD (the line between the second node and its handle) are almost but not exactly parallel.
This makes pattern-along-path harder to use, and means many SVG files that use p-o-p that opened correctly in 0.48 are not displayed correctly in 0.91 anymore. On most of my more complex SVG files which use pattern-along-path heavily, about 20-40 paths expose bad rendering and need to be manually tweaked to sidestep the problem.
The incorrect rendering seems to be unaffected by zoom-level, rotation or scaling of the path (using the F1 tool)
Sometimes the bug occurs in a very obvious manner, sometimes it is very subtle (which makes it very devious, as you don't tend to catch it before after the high-quality printing process...)
Here are some more examples of the bug in action:
https:/
https:/
https:/
https:/
tags: | added: livepatheffects |
Changed in inkscape: | |
status: | New → Confirmed |
importance: | Undecided → High |
tags: | added: regression |
Changed in inkscape: | |
milestone: | none → 0.92 |
Changed in inkscape: | |
assignee: | nobody → Alvin Penner (apenner) |
status: | Triaged → Fix Committed |
tags: | added: backport-proposed |
Changed in inkscape: | |
milestone: | 0.91.1 → 0.92 |
status: | Fix Committed → Fix Released |
Reproduced with 0.91.0. It appears that it's partially fixed in the 0.91.x stable branch (r13770) and trunk (r14151). Attaching modified test file which still shows the issue still exists. ~suv reported that this file looks as expected in 0.48.x (r10043).