inkstitch
inkstitch copied to clipboard
inkstitch
Power Strokes: Satin Columns
There is this life path effect named power stroke. It creates a stroke with various width. At the moment it is rendered as a fill obviously, but we could utilize it for satin stitch.
Cool!!
This really complicates the detection of what objects are satin columns. Maybe we should instead have a "convert power stroke to satin column" extension?
I understand what you mean, but I am a little bit opposed to that. Actually I was thinking into a complete opposite direction.
The biggest reason why people still use the zig-zag option and not satin column is the ease how they can create (and update). I was thinking if we could not merge the zig-zag pattern (/|/|) into satin columns and allow users to add rungs to simple lines as well. They choose if it is running stitch or satin stitch afterwards in the params.
I read often, that users wish for a simpler way to update their satin columns. That's why I was thinking about using the power stroke in the first place and it would be lost, if we just allowed them to convert it to satin with an extension. But I think it could be just one little step forward to more usability.
Maybe convert-to-satins could do like the stitch plan and preserve the original in a hidden layer? That's what I do manually before auto-routing and things like that.
I'm not saying we don't need the conversion tool, it would still have a purpose.
But wouldn't it be also nice if the non-dashed stroke could be a satin directly?
Yeah, I almost posted another post after I hit send: being able to put rungs on zigzags would be amazing regardless of whether convert-to-satin kept a backup layer.
That's a pretty neat idea! There's one thing I can see that's tricky with adding rungs to normal zigzags ("simple satin"). With simple satin you'll have a stroke width of 2mm for example. That means the rungs are 2mm too :(
That could perhaps be solved if we had the ability to use "external" rungs: rungs that are separate paths with a marker on them.
I guess it's lucky for us that Inkscape seems to always produce a shape with two sides that have exactly the same number of points. What if Inkscape changes that in the future?
I tried out the Power Stroke LPE for the first time, and I see what you mean: it is really easy to use compared to a satin column. I wish it could be asymmetric though.
I was thinking if we could not merge the zig-zag pattern (/|/|) into satin columns and allow users to add rungs to simple lines as well.
Here's why that's tricky. We don't actually have a good, reliable way to figure out what a path + stroke width actually looks like. Look at this for example:
It's a simple line with a corner. But how do we get from the path to the two rails? If we just make lines that are a fixed distance the left and to the right of the path, we end up with this:
That's just how the math works out. SVG renderers automatically figure this out and turn it into the top picture (ignoring the overlap in the red one). I couldn't find any library to do that for us, though -- other than shapely's parallel offset. But that gets confused for shapes like Ω. That's why Convert to Satin checks if Shapely got confused and breaks the path apart and tries again until it doesn't get confused. It's not a great solution.
I wanted to just have simple satin use Convert to Satin under the hood, but sometimes Convert to Satin produces really weird (invalid!) results.
I'd love it if we could figure this out, but I'm not sure how...
I guess it's lucky for us that Inkscape seems to always produce a shape with two sides that have exactly the same number of points. What if Inkscape changes that in the future?
I guess we then will have to add at least one rung under the hood as we do in the auto-route satin if we end up without rungs through splitting.
I'd love it if we could figure this out, but I'm not sure how...
Thanks for the problem description for convert to satin. I wasn't aware of that. Maybe unary_union could do a good job with that?
Ah, it's not just done with ading a rung. There will be more problems. We would need to find an other way to check for the end split pojnt. But we can easily access the original path and therefore the end node of that one. I think if they change behaviour in future, we can still figure it out.
I haven't tested this yet, but... What happens with a power stroke that touches itself, like the Omega shape?
Hm, I noticed, that it doesn't behave nice with sharp edges. Actually it has the same problems as a normal stroke would have (self crossing).
I guess I was a little bit too optimistic about the power stroke. I still like the idea though. Maybe we can figure it out - someday.
Can extensions read the input to live path effects? Perhaps a better algorithm would be to walk the center-line (input) path, doing a variable-width (from the handles) zigzag perpendicular to it as one would do in a free-motion satin stitch.
We have access to the path created by the life path effect as well as to the original path. Also we can access the handles and other variables from the life path effect.
That could work! I'm a little reluctant to reimplement power stroke though...
I don't think you'll have to re-implement the full power stroke login, just the topology part of it. On smooth curves, it always creates nodes on smooth curves across from each other. On corners, it always creates a cusp node on the inner corner and n nodes (a constant for each corner type) on the outer corner. The first node in the output path is the first node of the right rail, and the first mode of the left rail is either the first node or the last mode in the output depending on the start cap setting.
If you replicate the node pairing logic, you could calculate rungs from these pairs of nodes.
I'm going to close this. Power strokes in the next Inkscape version will support subpaths anyway. This means, there is no way to set manual rungs on path effect level (without converting to path). I still somehow like the idea to use power strokes, but maybe just as a converter.