I'm excited to tell everybody that I've finally found a great solution for transforming LPE paths into normal path:

1. You need to copy the path and open in a separate document.
2. Then "Save As" as a plain SVG.
3. Viola! Your LPE path now is a normal path, when you open the new SVG file.

But really... I feel like I'm overkilling the problem. Are there any more straightforward and obvious ways to do that?

I've got plenty reasons of why I (and I'm sure lots of people 'round here) need this. I feel like there must be at least some sort of plugin with such an ability.

Yes, overkill I'm afraid. Just select the path with the LPE applied and use Path > Object to Path.

No way 😂

Thank you, you saved my day. Actually, there was a similar qustion on the web somewhere, and the answer was is that LPEs are not supposed to be converted to normal paths at all, so I decided that there's no easy way.

Thank you @Xav 

Sometimes there are several LPEs on a path. Is there a way to "fix" one in place but leave the others as LPEs?

gohonleeds

Sometimes there are several LPEs on a path. Is there a way to "fix" one in place but leave the others as LPEs?

Sort of, but it's not easy.

The first thing to note is that LPEs apply in order, so you can't just fix any of them without fixing the ones before them in the chain. So if you have a path with 3 LPEs on it, you can fix the first one, the first and second, or all three. But you can't just fix the third one, or only the second and third.

To fix just the first one, for example, you can turn off the others using their eye icons in the Path Effects dialog, then use Object to Path. This fixes the first one, but the others are removed from the path. They are not, however, removed from the <defs> section of the document (until you use File > Clean Up Document), so they still exist, complete with all their settings. You can link them to the fixed path by editing it with the XML editor.

This is not very difficult to do, but it is quite tricky to explain - especially if you're not familiar with the internals of SVG files and the use of the XML editor. If you really want the details then reply here and I'll explain further. But in most cases I would guess that it's probably easier to just re-add the LPEs as normal and edit the parameters again.

Thanks for the detailed reply.

Right now I'm using the pencil tool in conjunction with a tablet, with pressure input on.

This works well. I can do nice variable-width pencil strokes.

However, all the paths end up with both Simplify and Power Stroke LPEs on.

I'm doing hundreds of these gestures at a time, and I'm finding having so many paths with LPEs on them is slowing Inkscape down.

But there's no "LPE Simplify Flatten" option when using pen pressure, so I'm unsure what to do next. Specifically, when I'm happy with the shape of my paths/gestures, and want to fix the LPE effects in place.

I tried "Object to Path" on them all but the end result is relatively simple gestures going back to having dozens nodes. I'm not experienced enough to know what is causing this. Just the simplification? Or power stroke as well? (When the LPEs were still there, I only seem to have a few nodes per gesture. Everything looks so perfect.)

Did the Simplify LPE just get removed (without doing anything) when I do "Object to Path"? I really want to apply the Simplify (a la "LPE Simplify Flatten) as part of removing it.

I've only been using Inkscape for a few weeks and there's really a lot to take in. Your FCM articles have been a great help by the way.

Any advice is appreciated, and I hope my ramble makes some sense, as I end up quite confused at the end of some days (today, lol)

Thanks,

I've done a bit more research. The reason for "Dozens of nodes" after "Object to Path" is obviously because of the power stroke. That makes total sense. The power stroke is adding a lot of complexity to a simple curve.

So slightly less confused now :-)

I guess some kind of "best practice" is what I need to figure out. I want to end up with:

1) A path with no LPEs on

2) A path without dozens and dozens of nodes for each gesture.

So is there a better way to achieve this goal than:

1) "Object to Path"

2) Ctrl+L to simplify the resultant path

(Still seems a bit weird/sub-optimal to have a Simplify LPE in place, and then have to do another one after the Object-to-Path operation... but who knows, that might be the thing to do)

To understand what's happening you need to first understand what a path is in SVG, the limitations that come with it, how LPEs work, and how they can be used as a 'cheat' to work round some of those SVG limitations.

First of all, a path is not, as you might expect, the visible line that gets drawn. A path is more of a mathematical boundary that is infinitely thin. It's just a conceptual line that connects one point to another (to another, to another...). Sometimes the last point is the same as the first point, resulting in a 'closed' path. Otherwise it's an 'open' path. But in either case, it's still an infinitely thin boundary that has no appearance of its own.

We can make it visible, however, by adding a fill or stroke. A fill simply says 'draw all the points inside this boundary in this specific style'. A stroke is more like dragging a paintbrush along the boundary to make it visible. But the path itself is still infinitely thin, even if we use a fill or stroke to make it visible for practical purposes.

One way to think about it is like the boundary of your garden. The boundary, in legal terms, is infinitely thin. Everything inside the boundary is part of your garden, everything outside is not. But the boundary itself has no thickness. For practical purposes, though, you will probably have a fence indicating the boundary (a thin stroke), or perhaps a wall instead (a thicker stroke). The presence of a fence or wall has no effect on the boundary itself, it's just a way of making a theoretical line visible.

SVG works like that. But when it comes to strokes, it can only use one thickness of 'paintbrush' at a time. You can have a thin stroke or a thick one, but not one that varies along the length of the path. There have been efforts to introduce variable width strokes into SVG, but as things stand currently the standard still only supports stroking with a single style.

That's a bit of a problem, artistically speaking, because people want variable width lines in their drawings. In your case you want them to reflect the pressure you're applying with the tablet, for example. And so we have the 'cheat' of LPEs.

The simplest way to think of an LPE is basically as an algorithm that takes an SVG path as its input, and produces a different SVG path as it's output. Because the output is another path, it can be passed directly into another LPE, and another, to form a chain of effects. But it's still an SVG path that goes in at one end, and another SVG path that comes out at the other end. Importantly, these algorithms are live: they get reapplied, in sequence, each time the original path changes. This makes them slower than simply drawing a path directly, because there's potentially a lot of maths to be done. This recalculation step could potentially also be triggered by changes in zoom, or when exporting a file - and probably other things too.

In the case of something like the Power Stroke LPE, for example, it is usually fed with a relatively simple path as its input. For the sake of understanding, let's assume it's receiving a simple, open path - just a few points that don't cross or close. In SVG this could only ever be shown as a line of constant width. But the output of the LPE is no longer a simple, open path - instead it's a closed shape representing how the path would look if SVG supported variable width strokes. For this new closed shape you're actually looking at the fill, not the stroke. You can add a contrasting stroke back onto the final result to see this clearly, if you want.

Within the SVG file itself, Inkscape performs a neat trick. It keeps track of the original path in its own private data attribute, while putting the output of the LPE chain into the standard SVG path definition. This means that LPEs (in theory) will still look the same when loaded into another program, such as a web browser. But when loaded into Inkscape, the application can hide the complex output and display just the small number of handles from the original path. That's why your path appears to be quite simple before you flatten the LPEs using Object To Path - it's not really that simple at all, but Inkscape is just showing you the first part of the process.

When you flatten the LPEs, Inkscape throws away the original path data, leaving the final standard SVG path in place. But now the program knows it can be rendered directly, and doesn't have to be recalculated all the time, making things a bit faster and more responsive. The downside is that you now see all those nodes that were previously hidden from you.

In the case of the Pencil tool with pressure sensitivity, you end up (potentially) with two LPEs applied:

• The Simplify LPE is present if the 'Smoothing' parameter is non-zero. It smooths out the jerks and wiggles in your original line and makes it such that the line you draw looks more like the one you thought you were drawing.
• The Power Stroke LPE is present if pressure sensitivity is enabled. It adds the variable line thickness - but in doing so, converts the open path into a closed, filled shape with a lot more nodes.

Hopefully you can now see why flattening the LPEs results in a lot of nodes. It's not that the act of flattening adds them, it's that doing so tells Inkscape to show you the final path rather than the original one. And although there's a Simplify present, it's simplifying the path before it goes into another LPE that will add more nodes anyway, so it doesn't have a huge effect on the number of nodes in the final path.

To get more of a feel for what's happening, I recommend adding the Show Handles LPE to a few test paths. That basically shows the handles for each node, so when added after a Power Stroke you can see all the extra nodes that the effect adds. You could add another Simplify between the Power Stroke and the Show Handles, to get an idea of the effect of trying to simplify the closed path if you want to go down that route.

In truth, there's not really a good way to avoid the extra nodes. They're either present but hidden from you when you use the LPEs, or they show up when you flatten the path. You can add another Simplify to the end of the chain, or use Path > Simplify on the flattened result, but there's no other way to get a 'simple' path out of Power Stroke, I'm afraid. And simplifying too much will distort the path too much.

Usually I recommend avoiding flattening of LPEs unless you specifically need to. Performance issues with lots of complex paths might be a valid reason, as is 'forcing' a more standard SVG file so you can be more confident about how it appears in other applications. Or perhaps you need to manually edit the result of one LPE chain before applying more effects. But if you can avoid flattening them then you generally retain more scope for manipulating and tweaking those paths in future.

Such a full answer which has made most things much clearer. So many thanks for that.

I do agree that flattening LPEs is generally a bad idea. It's just that last week I noticed my system was getting very stodgy. And after a lot of digging found out that it was because of all the work the LPEs were doing on my "strokes." I need to find a way to work such that I continue to work with LPEs but not so much that they overpower my system.

Just so I understand the LPE chain a bit better, and how it affects processing requirements. So Simplify LPE is the first LPE in the chain. That means it simplifies the basic wobbly path I drew. And it passes the simpler version into Power Stroke LPE for processing, right? The Power Stroke LPE isn't trying to process all the wobbly nodes?

If that is true then the LPE seems reasonably efficient, and I can't think of anything I can do to reduce processor load, apart from maybe the obvious things like only keeping 'live' stuff in the document if it needs to be there.

Is Inkscape good at optimizations, like 'only process stuff on-screen'? If so, I should stay zoomed in and scroll around a lot, and try not to zoom out lots.

Anyway, I have a much better handle on everything now. I don't actually want to change a lot. Just want my system to keep going better as I add more gestures. (I have lots of RAM, it's not that. Definitely a processor thing I guess)

There is one weirdness happening at the moment. Again, using the pencil tool with pen pressure option. If I start drawing a path and the stroke ends up in the same place as I started i.e. what I would normally identify as "closing the path", the path then disappears from the screen, regardless of what fill/stroke colors I have selected. What's the explanation for this behavior? Any way to recover the shape? Cheers.

Your understanding is pretty much spot on.

I don't know for certain (I'm not an Inkscape developer), but I suspect that most of the same rules of thumb apply with LPEs as with filters (the other obviously 'live' feature), when it comes to performance:

• Try to avoid zooming, as that tends to trigger a re-calculation.
• Panning is less of an issue, but Inkscape only buffers the visible area in the window, plus a little bit beyond - so large pans will also cause things to be recalculated.
• It doesn't recalculate the whole drawing every time, so keeping to a comfortable zoom level and panning as directly as possible will avoid it having to calculate other parts of the image that you're not bothered about.
• Hidden objects aren't generally recalculated, so try to hide paths you're not working on. You can hide them individually, or move them to a hidden layer above or below the one you're working on (use the keyboard shortcut for speed).
• If you need to keep the path around as reference, use Edit > Make A Bitmap Copy to create a snapshot of how it looks, then hide the original. Before finalising your work, delete the bitmaps and unhide the original paths.
  • As an alternative, you could duplicate the path and flatten it to produce a reference copy. You're more likely to accidentally end up editing the flattened version when you don't mean to, compared with using a bitmap.

For the closed path issue, I've been able to reproduce it myself. The path does get drawn for me, but it appears much larger than I drew it, and located to the bottom-right, beyond the page boundary. It also has no LPEs applied. I think it's quite obviously a bug - and a pretty major one at that! I recommend you report it, after reading this page: https://inkscape.org/contribute/report-bugs/

If you do report it, please post a link to the report here, as I'd like to follow it for my own information.

Those optimization tips sound great, and not too painful for workflow.

I will report the bug ASAP and post the link for you

https://gitlab.com/inkscape/inbox/-/issues/8683

By the way, I ran the 'displaced' path through a tester:

https://svg-path-visualizer.netlify.app/#M%2063.217584%2C748.2308%20C%20120.39734%2C726.45245%20178.28758%2C702.29981%20227.26357%2C664.67207%20393.21154%2C537.17595%2068.128989%2C449.00963%20-31.936701%2C496.57588%20-226.60114%2C589.10967%2063.217584%2C748.2308%2063.217584%2C748.2308%20Z

and the shape itself looks fine. And when you draw a new shape on top, you can still see the 'ghost' of the previous shape underneath and in the right place. Maybe you have some clue as to what is going on because I certainly don't.. 😀

Thanks for reporting it. I'm not altogether surprised to find it was marked as a duplicate of another bug, so for anyone else following this, the correct issue to monitor is this one:

https://gitlab.com/inkscape/inkscape/-/issues/1318

There are possible workarounds listed there. I was able to get it to behave by setting the document's units to 'px' and scale to 1. After that it was fine. I could even pick the same (A4) template again, which switched units back to 'mm' but adjusted the scale to what is presumably the correct value for the defined viewBox, and it continued to work as expected.

It does appear to be related to the Power Stroke LPE though. Turn off pressure sensitivity and the (fixed width) line appears in the right place. You can then add the Power Stroke LPE yourself (via the LPE dialog) and adjust the line thickness by hand - but I appreciate that's nowhere near as practical as using your tablet directly.

As for seeing the 'ghost' of the previous shape - that looks to me like a rendering bug, where the old data isn't cleared out properly, rather than intentional behaviour. I might be wrong though.

I've always worked in 'px' and '1' with a custom template (4000x4000), so yes, I can see it's something to do with that in combination with the pressure input  / Power Stroke LPE combo. It's not *just* the Power Stroke LPE because the triangle in/out shapes work just fine. I've only ever seen this bug when using the pressure input.

The 'workaround' for me will just be to draw as normal and as soon as a shape "disappears" I will hunt it down and drag it back to the correct place :-)

Is three years an unusually long time for a bug like this to be around?

gohonleeds

Is three years an unusually long time for a bug like this to be around?

Not really. Inkscape is a mostly volunteer developed application, so any given bug relies largely on an individual developer being sufficiently motivated to work on it and having the necessary technical skills to do so. A bug is more likely to get fixed if it's an easy change with few potential side-effects, or if it's directly affecting a developer's own use of the program. I imagine this is a tricky one to address, and clearly hasn't caused enough of a problem to any of the developers for them to focus on it above other issues.

It may be possible to pay a developer to work on a bug fix. I believe DoctorMo accepts sponsorship for some of his work, for example. But that would require finding enough money to make it worth someone's while to spend time on this.

For what it's worth, I've known bugs in much larger Open Source projects (Firefox, for example) to receive a fix after more than a decade. Conversely, other bugs barely make it onto the bugtracker before someone has fixed it. Short of either learning how to fix it yourself, or paying someone to do so, you're at the whim of the developers' motivations and the general project roadmap, I'm afraid.