Ceci est une ancienne révision du document !
Last month, I spent the entire article looking at the Path > Split Path operation that was added in version 1.2. Although version 1.3 added two more path operations, they’re essentially two variations on the same theme, so won’t take quite as much space to describe. These are Path > Flatten and Path > Fracture. Let’s begin with an example that consists of a star drawn over a rectangle:
You probably give little thought to such layering of elements, which you undoubtedly use all the time in your Inkscape projects. But to understand how these new operations work, it’s important to comprehend what’s actually happening in terms of the SVG content. Both these objects are in the same layer, but they live at different positions in the Z-stack, usually determined by the order in which they appear in the file. This is the “painter’s model” that SVG uses – earlier objects in the file can be “painted over” by later objects. In this case, the blue star is painted over the red rectangle, and since there’s no transparency involved, we see a solid blue color even in the overlapping regions. If we were to imagine looking at this arrangement from the side, it might look something like this:
I’ve drawn this to look as though the star is casting a shadow on the rectangle. In practice that purple shadow actually represents the area of overlap between these objects.
So far, I probably haven’t told you anything you didn’t already know, even if that knowledge doesn’t usually play an active role in your use of Inkscape. Indeed, for most people, the way that the shapes are ‘layered’ is purely an academic consideration: in practice, Inkscape draws solid blue pixels on the screen and you don’t need to concern yourself with the fact that they’re actually obscuring some red pixels from the rectangle behind. But there are a few situations where this knowledge is vital.
Consider screen printing – often used for printing designs onto T-shirts, posters and fabrics in general. It’s somewhat fallen out of fashion now, as on-demand printers can put your full color design onto all manner of items without the hassle of setting up your own mini print shop. But for artistic, budgetary, or other reasons, screen printing still lives on. In this process, each color in the design is printed by forcing ink through a mesh screen that carries the part of the design showing that one color alone. Repeat this with a different screen for each color, and you can reproduce complex designs, provided they only have a limited number of colors.
In the case of our design above, a naive approach would be to create one screen with a rectangle, and one with a star. First use the rectangle mesh to print in red, then align the star mesh and print the blue parts. But in this case we’re not dealing with pixels in memory that don’t exist until the final rendering step – we’re dealing with wet inks that will merge and run into each other. Our final design won’t show a blue star and red rectangle, but rather parts of each, with a muddled purple area where the shapes intersect.
What we actually want is for that overlapping area to be removed before printing. We want the design (when viewed from the side) to look more like this, with the intersection cut out of the red rectangle:
In this particular case, with just two objects to consider, it’s not too tricky to duplicate the star and use Path > Difference to cut it out of the rectangle. But how about when three or four objects overlap – let alone more.
Just adding a yellow rectangle and a green circle into the mix starts to make the use of Path > Difference rather complex. The green circle has to be cut out of all three objects below it, the yellow rectangle out of the two below it, and so on. The more objects, colors or complexity, the harder it is to manually perform all the operations required to produce a final result with no overlapping parts.
What is needed is a simple way to modify the image so that the final result consists only of the visible parts of paths, with no overlapping sections. In raster graphics programs, this is a common task for combining multiple layers into one, where it’s referred to as ‘flattening’ the layers. And so, with Inkscape 1.3, we now have Path > Flatten to achieve the same effect with paths. Selecting all four paths in this example and applying this operation results in the following four objects (moved apart, and with strokes added for clarity):
For your average screen printer, this will be fine, and represents a much faster way of achieving what would previously have been a tedious and error-prone series of Boolean operations.
The other new path operation does something similar, but breaks elements apart even further. When using Path > Fracture, you not only get the flattening effect, but the overlapping shapes are further broken apart as though some Path > Division shenanigans had also taken place. You can see how, in this example, it results in far more individual paths than the Flatten operation (again, moved apart and strokes added for clarity):
To be honest, I haven’t yet thought of a good example of where flattening and splitting paths in this way would be useful. But perhaps that says more about my lack of imagination, and this feature might be just the thing you’ve been waiting for to revolutionise your Inkscape workflow.
While we’re dealing with the Boolean operations there’s another change in 1.3 that needs to be discussed: what happens when you use Path > Object to Path with a text object. If you’re getting a sense of déjà-vu, it’s because this is a topic that has cropped up previously in this series, as the Inkscape developers seem insistent on modifying the behaviour every few releases.
Up to version 0.47, this operation simply converted the entire text content into a single complex path. This made it extremely difficult to work with the individual characters (technically, glyphs), if that was your goal. Version 0.48 changed the behaviour to create a single group consisting of one path per glyph. This made some tasks a lot easier, and if you really did want just a single path, using Path > Union rather than Object to Path would still achieve that without having to ungroup and combine separate paths. All was well, until version 1.0 broke the Path > Union trick… but the developers fixed it once more in 1.0.2 (see part 100 of this series for more details).
So, aside from a brief period after version 1.0 was released, this functionality has been pretty stable: Path > Object to Path creates a group containing one path per glyph, while Path > Union creates a single path for the entire text object. Everyone was happy, and there was definitely, absolutely, no need to upset that status quo, right?
Apparently the Inkscape developers either didn’t get the memo, or there’s a secret cabal of disruptive users who never really got over the change from v0.47, because version 1.3 brings back the bad-old days when Object to Path created a single path for the entire text, with no option to create separate paths for each character. But wait! Don’t forget last month’s column, where I looked at the Path > Split Path operation. Surely that can help. Well… maybe. Sometimes. Sort of.
To use Path > Split Path you first need a path to split. Unfortunately it won’t auto-convert a text object on your behalf, so you have to use Path > Object to Path first, and then follow it up with Path > Split Path. However, as I noted last month, as useful as the Split Path function is, it doesn’t understand that you’re working with glyphs. The dot over every ‘i’ and ‘j’ becomes a separate path object, as do accents over characters, or the dots at the bottom of question and exclamation marks. If you’re lucky you might get away with using this function directly, but more often than not, there will be additional manual work required to re-combine the disconnected parts of such characters.
There’s a “solution” to this problem which should be present in the 1.3.1 release (which will probably already be out by the time you read this). This version adds a Text > Text to Glyphs menu entry, which can be used to split a text object into individual glyphs before you use Path > Object to Path on them. I’ve tried it in the 1.3.1 Release Candidate build, and it works… but it’s still adding an extra step that wasn’t necessary before. If you’re still on version 1.3, you may be able to use the Text > Split Text extension (in the Extensions menu) to achieve the same result – though my own experience with this has been extremely poor, with the split characters being badly misplaced.
Speaking of badly misplaced characters, the new Text to Glyphs function also moves your text around if you’ve adjusted the vertical position or the rotation of individual characters.
The example below shows the results of both the extension, and the new function. The text in the middle is the original: I’ve deliberately used two fonts, with one of them in different weights and styles. I’ve also manually adjusted the vertical height of some of the letters, and the rotation of others.
The line at the top is the result of using the extension. To be clear, I haven’t moved it to that location – the extension decided to place the result at the top of the page, ignoring the position of the original text object. It’s done a good job of preserving the fonts, weights and styles. But not only has it ignored the vertical adjustments and the rotation, but it also has very odd ideas about the spacing between characters. The bottom line shows the result of the Text to Glyph function. This time the split text appeared in the same location as the original, so I have moved it down. You can see that the fonts, weights and styles have been preserved, but vertical alignment and rotation have, again, been ignored. Of the two, however, it definitely gives the better result.
Let’s compare this to the behaviour of 1.2.x. In this case, the original text is at the top, and two copies have been made and moved down so you can see the result of each operation more clearly. The second line is the result of Path > Object to Path. As you can see, it looks identical to the original in both style and position. But in practice, this is now a group of individual paths, one for each glyph. The third line shows the result of Path > Union, which again preserves the style and position, but loses the color change due to having created a single complex path for the whole text.
In my opinion this change in behaviour is a massive step backwards. It totally removes some perfectly reliable functionality from 1.2, replacing it with options that are far less functional – but it doesn’t appear to offer any new capability that makes this trade-off worthwhile. If you ever play around with the alignment and rotation of individual characters in your text, the only way to create a group of paths from the carefully-placed glyphs is now to use Object to Path, then Split Path, then manually fix up any characters that are made up of multiple parts. But you’ll also lose any color changes along the way, and will have to re-apply those manually as well. It turns a single step operation into something vastly more complex.
I wonder how long it will be before I’m writing a column to describe yet another change in this behaviour…?