Ceci est une ancienne révision du document !
Over the next few instalments I’ll be looking at the new Live Path Effects (LPEs) that have been added with Inkscape 1.0 and 1.1. Earlier articles in this series provide a general introduction to LPEs and what they are (part 42), as well as a deeper dive into the LPEs that arrived with earlier Inkscape releases (parts 42 to 47, 65 to 69). The previous instalment detailed the more general changes to the LPE dialog that took place with version 1.0, but this month I’m going to look at the first of the new LPEs, plus an old one that has had something of a rebirth.
Dashed Stroke
At first glance there doesn’t appear to be an obvious need for an LPE that renders the stroke of an object as dashes. After all, the Fill & Stroke dialog already offers various dash patterns which form part of the native SVG format (remember, LPEs are an Inkscape-specific extension). But although the standard SVG dashes are often sufficient, they do lack some nuance in the way they’re distributed along a path which can give a less than aesthetically pleasing result. This is the niche that this new LPE aims to address. As a quick example, look at these stroked stars, the red one on the left using standard SVG dashes, and the blue one on the right using the Dashed Stroke LPE.
Pay close attention to the way that the corners – both concave and convex – are rendered. The SVG version is mirror-symmetric along the vertical axis, but only because I adjusted the dash offset to give that effect. Without that manual intervention there was no symmetry to the dashes at all. Even with that change, however, the corners differ as you move around the star: for the tips of the shape we would probably like them all to look like the point at the top, and not like the remaining four. None of the inner corners are really what we would like in most cases. Notice that the LPE version achieves exactly the right look, with the corners all appearing pleasingly similar and symmetric.
Let’s look at another example. Dashed outlines are commonly used around simple rectangular boxes in flow charts and other diagrams. Which do you think looks better: the red SVG version (left) or the blue LPE version (right)? Once again, focus on the corners.
The reason for this difference is that the SVG stroking spec uses a very simple algorithm to determine how to draw the lines and spaces. It simply starts at the beginning of the path and draws a series of alternating dashes and spaces, based on the pattern described in the stroke-dasharray attribute or CSS property. It doesn’t care about curves or corners, it just plods along from start to finish rendering a repeated series of strokes and dashes, regardless of the underlying shape. You can control the position of the first dash, using the stroke-dashoffset attribute or property (which is exposed via the Fill & Stroke dialog in Inkscape), but all that does is shift the entire pattern along. It doesn’t affect the length of each stroke or space, so you are still likely to end up with unbalanced dashes as they wrap around the corners of your shape.
The LPE, on the other hand, works a little differently. The biggest change is that it can work on each segment of a path individually, rather than treating the entire path as a single stretch to be dashed as one. This is the secret of those better looking corners – drawing half a dash at each end of a segment results in dashes that are pleasingly symmetric as the path turns a corner. Let’s look at the options available in this LPE, and the settings I used for the blue rectangle.
I’m going to describe these parameters out of order, as this is the best way to explain what each option does. I’ll start with the “Use segments” parameter: when unchecked this results in the other parameters applying to the entire path (much like the native SVG dashes). When checked, each segment of a path is treated separately. In most cases you’ll probably want this checked.
Going back to the top, the “Number of dashes” parameter defines the number of dashes that will be rendered along the length of the whole path, or along each individual segment. But the actual count will also depend on the “Equalize dashes” option, as we’ll see shortly. This parameter is at the heart of the fundamental difference with the LPE dashes, though: SVG dashes don’t have a count or limit, they’ll simply keep rendering as long as there is any path left to fill; the LPE dashes, on the other hand, aim to fit a specific number of dashes into each path or segment, subdividing the available length according to this parameter and then distributing the dashes and spaces evenly within.
The relative lengths of the dashes and spaces can be adjusted using the “Hole factor”. Leave it at zero to have them the same size, increase it (up to +0.99999) to increase the size of the dashes and reduce the spaces, or decrease it (down to -0.99999) to adjust the balance in the opposite direction. Reducing it to its lowest value results in each dash appearing as nothing more than a pair of line caps, as set in the Fill & Stroke dialog: a circle (for round caps) or a square (for square caps). Watch out if you use the “Butt cap” style, however, as that effectively causes the dashes to disappear completely at the lowest hole factor. Note, however, that using a single ratio like this means that the LPE can’t produce the sort of dash and dot combinations that the stroke-dasharray allows for in normal SVG strokes.
The “Half start/end” parameter determines whether to only draw half a dash as the start and end shapes (checked), or to draw a full dash at the start and end if possible (unchecked). Usually this is best left checked in order to gain the aesthetic benefits of symmetry and even spacing. Each half dash still contributes to the “Number of dashes” count, so a count of 5 with this parameter enabled actually means 3 whole dashes and two half dashes, rather than the 4 whole dashes (plus two halves) that you might expect if you were adding the parts up numerically.
Finally, the “Equalize dashes” parameter has the potential to upend the “Number of dashes” count entirely. When this is checked, the algorithm first creates the desired number of dashes for the shortest segment in the path. The length of each dash in that segment is then used when rendering all the other segments, fitting more than the actual count in if there is space. A demonstration might make this a little clearer.
In the image below, the two paths are the same, but the top one has “Equalize dashes” unchecked, whereas the lower one has it checked. I’ve positioned some vertical guides to make it clearer where the nodes of the path are – i.e. where each segment starts and ends. The top path honours the “Number of dashes” count completely: each segment has 5 dashes (3 whole, 2 half). But this leads to different spacing between the dashes across the segments, and even differently sized dashes in the middle two segments where they’ve had to be squeezed into a smaller space.
The lower path, on the other hand, clearly shows that all the dashes and spaces are even across all the segments. But it does this at the expense of the “Number of dashes” value. That parameter is used when calculating the smallest segment (the third one), but then the resultant dash and space size is simply used for all the other segments, regardless of the count. As you can see, the end result looks better, and is probably what you are likely to want, but the first and last segments have way more than 5 dashes each.
There’s one additional part of the UI in the screenshot from the LPE dialog: not another parameter, but a note in a box, which says ‘Add “Fill Between Many LPE” to add fill’. What on earth does that mean, and why is it necessary?
Fill Between Many
Remember that the output from an LPE is just an SVG path, so all the clever things that LPEs can do must ultimately be rendered using normal SVG capabilities. As we’ve already seen, raw SVG can’t produce the sort of dashes that we’re getting from the Dashed Stroke LPE, so what actually are we seeing in our rendered output?
The result is actually a new complex path, made up of lots of individual subpaths, one for each visible dash. Trying to add a fill to this will actually just fill the subpaths, not the whole shape. Because most of the subpaths only have two nodes, even that fill isn’t generally visible. The exception is the corners, where three nodes are used in a triangular configuration. Sure enough, adding a fill to a Dashed Stroke path does result in a web of colour in the corners, but not the filled shape we’re looking for. As an example here’s our star from earlier, but with the stroke width reduced for clarity and an orange fill applied.
This has long been an issue for many LPEs, not just the Dashed Stroke, so the Inkscape developers addressed it head-on a long time ago, by adding the “Fill Between Many” LPE back in version 0.92. I covered this LPE in some detail back in part 67 (FCM issue #127), though the UI has expanded a little since then. In older versions you only had the ability to add paths to the LPE, flagging some of them as needing to be reversed. The new UI, when used with the same “Frankie” image I used in part 67, looks like this.
The basic functionality remains the same: you have to create a sacrificial path on which to apply this LPE, then add each of your source paths by copying each one to the clipboard and adding it to the list in the LPE, as described in the earlier article. It can be a time-consuming and difficult process when dealing with lots of paths, though it’s not too bad for adding a fill to a shape with the Dashed Stroke LPE as there’s only one path to add in that case. These are the steps needed to add a fill to our rectangle, for example: • Draw a sacrificial path (usually just a simple two-node line) • Add the Fill Between Many LPE to the sacrificial path • Select the path which has the Dashed Stroke LPE applied (the rectangle) and copy it to the clipboard • Re-select the sacrificial path in order to bring up the UI for the Fill Between Many LPE • Click the “Link to path in clipboard” button to add the Dashed Stroke path to the list • Adjust the fill and stroke values to suit your needs
With luck you’ll now find that your rectangle has a fill, but things don’t always go so smoothly. In my own experiments, trying those steps with a star rather than a rectangle results in either no fill, or an oversized fill object that is wrongly positioned and can’t be moved. There are definitely some bugs in this LPE that have yet to be ironed out.
Compared with v0.92, the newer version of this LPE also provides some additional parameters to tweak. There is a “Visible” checkbox for each path, allowing you to temporarily remove it from the filled shape, perhaps to test whether or not it is contributing anything useful prior to completely removing it from the list. The “Join subpaths” checkbox lets you fill each subpath individually (unchecked), or use the older behaviour of joining the subpaths to create a single shape to fill (checked). The latter is almost always going to be what you want. Another checkbox (“Close”) now lets you leave the new path unclosed between the first and last paths in the list – probably more useful if you are using this LPE to add an extra stroke rather than a fill and, again, usually something you would want to leave checked. Finally the “Autoreverse” option overrides the individual “Reverse” checkboxes for each path: with this checked the algorithm will try to join paths based on the proximity of their endpoints, rather than strictly following the direction of each path. Usually this does a good job, and is best left checked, but you do have the option to turn this off and manage path reversal on a per-entry basis as before, should you wish to.
The pop-up menu is also a new addition, choosing how the source paths should be interpreted. Usually leaving this as “With Spiro or BSpline” is a good option: this will essentially use the shape you originally drew, whether it was created using simple SVG paths, or you used the Spiro or BSpline options that Inkscape exposes in some drawing tools. In practice these are implemented as LPEs, so this option tells Inkscape to use the output from those LPEs as the source, if they exist, or to use the plain path data otherwise. Alternatively you can select “Without LPEs” to only use the original path data, regardless of any LPEs applied. Conversely the “With all LPEs” option will use the path data that comes out of whatever series of LPEs has been applied to the shape. Be aware that this can quickly lead to very complex shapes if you’re not careful, so isn’t often the choice you want.
Looking back at the number of steps needed to add a fill to a path with the Dashed Stroke LPE applied, you may feel it’s not worth the extra effort and confusion, preferring to stick to SVG dashes or to draw the fill as a separate object. The “Fill Between Many” LPE can certainly be a tricky feature to get your head around, and in other use cases where you need to add multiple paths to the dialog it can be a time consuming pain. Luckily the Inkscape developers have realised that this complexity gets in the way of an otherwise useful feature, so with version 1.1 they’ve added a new menu entry, Path > Fill between paths, which will silently create a sacrificial path and add the “Fill Between Many” LPE to it, already populated with any paths from your drawing that were selected at the time. This makes it trivial to use this LPE in most cases: just select the path or paths that need to be filled and select the menu option. You can then select the newly added fill in order to access the LPE parameters if you need to (e.g. to reverse specific paths).
Note that the sacrificial path added by Inkscape is of zero length: its “inkscape:original-d” attribute just consists of an “M 0,0” command, which doesn’t actually draw anything. As such, be careful not to either hide the LPEs visibility, or that of all its listed paths, otherwise you won’t be able to select it on the canvas. In that case you’ll have to find it in the XML editor (look for a path with that “M 0,0” value) in order to select it for further editing or deletion.
This new menu entry is a great addition for working with LPEs, as it helps to get around one of the most fundamental problems most users will come across as they begin to use them. For this reason alone it may be worth upgrading to version 1.1.x if you haven’t already done so. It’s a shame, however, that the “Fill Between Many” LPE, even when added using this menu entry, can still be rather buggy, even for simple examples. Hopefully future releases will make it more robust, which will help to make LPEs in general a far more useful tool than they already are.