LPEs must be affected by the "scale stroke width" switch

Bug #172137 reported by Buliabyak-users on 2007-09-21
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

If "width in units of legnth" is off (default), then scaling a path
with a pattern leaves the width constant, thus changing the shape of
the result. This is sometimes desired and sometimes not. I propose
that the "Affect stroke" button on the selector toolbar must affect
this as well, so that I could scale or not scale pattern width at
will. (Or maybe add another button there: Affect Path Effect, separate
from the stroke.)

Here's what needs to be done. In sp_path_set_transform, there's a call
to sp_item_adjust_stroke which scales the stroke of the transformed
path. You need to add a generic scale method to the LPE object and a
function that would call it for the given item if the item is a path
using LPE. Each kind of LPE will "scale" itself in different ways; for
path-on-path, it is scaling the pattern width, for a rounding-corners
effect it is scaling the radius of the roundings, etc.

So, in the call from sp_path_set_transform, you just scale the LPE
proportionally and unconditionally. For path-on-path, depending on the
"width in units of legnth" switch, it will either do nothing (if it's
on) or scale the width by the given expansion (if it's off). Then, the
same function is also called from sp_item_write_transform, where it
looks up the user preference first. This means that the "do not scale"
mode is done a little wastefully: it is first scaled up in
sp_path_set_transform and then back down in sp_item_write_transform.
But that's the way it's done for stroke scale, and I think you just
need to repeat all this for LPEs as well.

Ryan Lerch (ryanlerch) on 2007-12-13
Changed in inkscape:
importance: Undecided → High
status: New → Confirmed
jfb (jf-barraud) wrote :

I think that the main issue behind this is that transforming an object before or after applying an lpe is not the same.

Therefore, I think the natural answer is to use effect stacking.

A basic "transform effect" should be defined, and whenever you rescale, rotate or transform an object carying such an lpe effet, the transform is added as a new transform effect at the end of the stack (or merged with the last one if it is already a transform effect) rather than as a transform attribute.

The result is then wat you visually expect. The benefit of this solution is that it is uniform for all lpe, and handles the case of several effects: propagating the transforms into all the parameters of all the effects might be tricky.

In the particular exemple of skeletal stroke, you can
-scale the skeleton without scaling the pattern by inserting a transform effect *before* lpe-pattern-along-path.
-scale both skeleton and pattern by inserting a transform effect *after* the lpe-pattern-along-path.

Of course, this requires to have a user friendly lpe stack, but I think we'll sooner or later need one!!


su_v (suv-lp) on 2012-11-08
tags: added: transformations
jazzynico (jazzynico) on 2013-06-24
Changed in inkscape:
status: Confirmed → Triaged
Jabiertxof (jabiertxof) wrote :

Pattern along path(r.14778), Fillet Chamfer, Power Stroke and Bend Path now handling scaling.
There is something more or we can close the bug?

Jabiertxof (jabiertxof) wrote :

Close the bug

Changed in inkscape:
assignee: Johan Engelen (johanengelen) → Jabiertxof (jabiertxof)
status: Triaged → Fix Committed
su_v (suv-lp) wrote :

@Jabiertxof - are these fixes included in the stable release branch for 0.92?

Jabiertxof (jabiertxof) wrote :

This weekend recheck it.

Jabiertxof (jabiertxof) wrote :

Are included in 0.92.x

su_v (suv-lp) wrote :

@JazzyNico - could you please set milestone to 0.92? Thanks a lot ...

jazzynico (jazzynico) on 2016-09-09
Changed in inkscape:
milestone: none → 0.92
su_v (suv-lp) wrote :

The changes in rev 14778 for the issue described/tracked here (bug #172137) seem to contribute to or expose the flaky / faulty node-editing behavior of the Pattern-Along-Path LPE when editing the second node for the first time (see also bug #1621234, comment #4).

[1] https://bazaar.launchpad.net/~inkscape.dev/inkscape/trunk/revision/14778

su_v (suv-lp) wrote :

Rev 14778 for Pattern-Along-Path had a flaw: the initial actual scale of the pattern width of a path drawn with shape 'Ellipse' is not stored correctly in the SVG source (i.e. initial rendering on-canvas does not necessarily match the prop_scale written to the path effect definition in the <defs> section). An update of the path effect definition can only be forced if the 'Path Effects' dialog has been opened at least once in the current session (see workarounds below) - note that the user has no need for the 'Path Effects' dialog when using a shape for the drawing tools (thus this flaw could have been exposed easily).

Steps to reproduce with _archived_ build:
1) launch inkscape with default (new) prefs, default new doc based on en_US template
2) zoom to 100% ('1')
3) switch to the bezier tool ('B')
4) select 'Ellipse' as shape
5) draw a (curved) path
6) save drawing, close window
7) reopen just saved drawing
--> the path now renders much wider (at '1.00')
8) draw a new path (same settings)
--> unexpectedly, the new path and the old path render with different pattern widths on-canvas
9) save drawing, close window
10) reopen just saved drawing
--> both paths now render with the same width, but much wider than originally drawn

Known workarounds:
Before saving the drawing (step 5, 9), force update of width parameter value:
a) open 'Path Effects' dialog, de- and re-select just drawn path
b) open 'Path Effects' dialog, switch to the node tool, use <TAB> to select a node, nudge it with cursor keys (e.g. a tick up and down again) to force update of width parameter

Note that above flaw is present in both pre-releases of 0.92.x (tarballs of 0.92pre0, 0.92pre1) - on the other hand current builds of lp:inkscape/0.92.x and trunk do _not_ expose it because of the commit which in return caused bug #1621234.

Proposing to reopen this report - not all aspects of 'stroke' scaling (e.g. via width parameter) for LPEs had been fully solved (work-in-progress is currently tracked in bug #1621234).

su_v (suv-lp) wrote :

Reopening - scaling of the pattern width of path effect 'Pattern along Path' depending on the 'scale stroke width' setting no longer works with lp:inkscape/0.92.x rev >= 15054 (presumable same status in trunk, since r15054 was a backport of trunk r15089): the pattern width is not affected by the scaling.

Affects 'regular' application of the PaP path effect as well (draw pattern path, copy to clipboard, draw skeleton path, apply PaP LPE, paste pattern from clipboard; scale the path which has PaP LPE applied using the select tool).

Changed in inkscape:
status: Fix Committed → In Progress
Jabiertxof (jabiertxof) wrote :

@su_v: Could you try with fix for bug #1621234 Use one of the patches "fix-bug-1621234.v8.xxxxxxx".
For the scale be sure you have in select tool selected scale stroke width.

Jabiertxof (jabiertxof) wrote :

Removed 2 last comment because wrong bug. Folow #1621234 that has fixes to this bug.

su_v (suv-lp) wrote :

Jabiertxof wrote 7 hours ago:
> Could you try with fix for bug #1621234 Use one of the patches
> "fix-bug-1621234.v8.xxxxxxx". For the scale be sure you have in
> select tool selected scale stroke width.

Done, as well as with v9 and v10.

The earlier described “flaw” with regard to 'Pattern Along Path' LPE is still present, and also exposed when scaling a just drawn path (with shape 'Ellipse') with 'stroke scaling' turned on:

Unless the Path Effects dialog was opened at least once in the current session (i.e. not restored from last session - that would be equal to opening it in the current session), then any scaling applied to the path with the select tool is not recorded in the path effect definition (SVG source) as value of the 'prop_scale' attribute. The current value though seems to be held somehow in memory and is used to generated the output on-canvas during the current session.

Steps to reproduce:
(please test with new prefs, and in a session with a new doc based on the default template):
1) launch inkscape 0.92.x patched with latest
2) zoom to 100% ('1')
3) switch to the bezier tool ('B')
4) select shape 'Ellipse'
5) draw a path
   (e.g. a curve with cusp start, smooth middle and cusp end node)
6) switch to the select tool ('S')
   Verfiy that stroke scaling is ON (default with new prefs)
7) scale the path uniformly by dragging the upper right transformation
   handle with Ctrl pressed

--> the width of the pattern scales up (or down) as expected.

8) Variants to expose the 'flaw':

8a) duplicate the path and move the duplicate aside
   --> the duplicate reverts to prior pattern width

8b) keep path selected, open the XML Editor
   select the path effect definition in the prefs
   inspect the value of 'prop_scale' attribute (unchanged initial '1')
   open the Path Effects dialog (Shift+Ctrl+&)
   check the 'prop_scale' value again:
   --> now its value has been updated
   (AFAICT corresponds to the path rendered on-canvas)
   further scaling of the path will update the prop_scale value

8c) save and reopen cycles as described earlier

In my understanding, it should not be required to have the 'Path Effects' dialog open in order to have the scaling (the width of the pattern) actually updated to the PaP path effect definition (users do not necessarily need that dialog when working with pencil/bezier shapes).

Slight variations are additionally exposed when copy&pasting the path into a new document (based on the same default template i.e. same document scale) and duplicating the copy afterwards, but that propably needs tracking in a separate report.

su_v (suv-lp) wrote :

Sorry, minor typo in comment #15:
- select the path effect definition in the prefs
+ select the path effect definition in the <defs>

Jabiertxof (jabiertxof) wrote :

Ok I just update my patch to fix it:

Thanks for the review!

su_v (suv-lp) wrote :

Scaling with 'scale stroke width' ON for path with PaP LPE successfully tested with lp:inkscape/0.92.x r15075 + fix-bug-1621234.v11.FixScalePatternAlongPath.patch (from bug #1621234) - the described 'flaw' no longer reproduces.

Jabiertxof (jabiertxof) wrote :

Fix commited frop patch in bug #1621234:
trunk : 15111
0.92.x : 15076

Changed in inkscape:
status: In Progress → Fix Committed
Bryce Harrington (bryce) on 2017-01-09
Changed in inkscape:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers