Full Circle Magazine FR

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
**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.**

Le mois dernier, j'ai consacré tout l'article à l'opération Chemin > Découper le chemin (celle du bas - Maj+Ctrl+Alt+K) qui a été ajoutée dans la version 1.2. Bien que la version 1.3 ait ajouté deux autres opérations de tracé, il s'agit essentiellement de deux variations sur le même thème, qui ne prendront donc pas autant de place à décrire. Il s'agit de Chemin > Aplatir et Chemin > Fracturer. Commençons par un exemple qui consiste en une étoile dessinée sur un rectangle :

Vous n'avez probablement pas réfléchi à ce type de superposition d'éléments, que vous utilisez sans aucun doute tout le temps dans vos projets Inkscape. Mais pour comprendre le fonctionnement de ces nouvelles opérations, il est important de comprendre ce qui se passe réellement au niveau du contenu SVG. Ces deux objets se trouvent dans la même couche, mais à des positions différentes dans la pile Z, généralement déterminées par l'ordre dans lequel ils apparaissent dans le fichier. Il s'agit du « modèle du peintre » utilisé par le SVG : les objets antérieurs du fichier peuvent être « recouverts » par les objets postérieurs. Dans ce cas, l'étoile bleue est peinte sur le rectangle rouge, et comme il n'y a pas de transparence, nous voyons une couleur bleue unie même dans les régions qui se chevauchent. Si nous devions imaginer que nous regardons cet arrangement de côté, cela pourrait ressembler à quelque chose comme ceci :

J'ai dessiné ceci pour donner l'impression que l'étoile projette une ombre sur le rectangle. En pratique, cette ombre violette représente en fait la zone de chevauchement entre ces objets.


**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.**

Jusqu'à présent, je ne vous ai probablement rien dit que vous ne sachiez déjà, même si cette connaissance ne joue généralement pas un rôle actif dans votre utilisation d'Inkscape. En effet, pour la plupart des gens, la façon dont les formes sont « superposées » est une considération purement académique : en pratique, Inkscape dessine des pixels bleus solides à l'écran et vous n'avez pas besoin de vous préoccuper du fait qu'ils masquent en fait quelques pixels rouges du rectangle situé derrière. Mais il y a quelques situations où cette connaissance est vitale.

Prenons l'exemple de la sérigraphie, souvent utilisée pour imprimer des dessins sur des T-shirts, des affiches et des tissus en général. Elle est quelque peu tombée en désuétude aujourd'hui, car les imprimeurs à la demande peuvent imprimer votre dessin en couleurs sur toutes sortes d'articles sans que vous ayez à créer votre propre mini-imprimerie. Mais pour des raisons artistiques, budgétaires ou autres, la sérigraphie est toujours d'actualité. Dans ce processus, chaque couleur du dessin est imprimée en forçant l'encre à travers un écran de maille qui porte la partie du dessin montrant cette seule couleur. En répétant cette opération avec un écran différent pour chaque couleur, il est possible de reproduire des motifs complexes, à condition qu'ils ne comportent qu'un nombre limité de couleurs.

Dans le cas de notre dessin ci-dessus, une approche naïve consisterait à créer un écran avec un rectangle et un autre avec une étoile. On utilise d'abord le maillage du rectangle pour imprimer en rouge, puis on aligne le maillage de l'étoile et on imprime les parties bleues. Mais dans ce cas, nous n'avons pas affaire à des pixels en mémoire qui n'existent pas jusqu'à l'étape finale du rendu - nous avons affaire à des encres humides qui vont fusionner et se heurter les unes aux autres. Notre dessin final ne montrera pas une étoile bleue et un rectangle rouge, mais plutôt des parties de chacun, avec une zone violette confuse à l'intersection des formes.

**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):**

Ce que nous voulons en fait, c'est que cette zone de chevauchement soit supprimée avant l'impression. Nous voulons que le dessin (vu de côté) ressemble à ceci, avec l'intersection découpée dans le rectangle rouge :

Dans ce cas particulier, avec seulement deux objets à considérer, il n'est pas trop difficile de dupliquer l'étoile et d'utiliser Chemin > Différence pour la découper dans le rectangle. Mais qu'en est-il lorsque trois ou quatre objets se chevauchent - et a fortiori plus ?

Il suffit d'ajouter un rectangle jaune et un cercle vert pour que l'utilisation de Chemin > Différence devienne assez complexe. Le cercle vert doit être découpé dans les trois objets situés en dessous, le rectangle jaune dans les deux objets situés en dessous, et ainsi de suite. Plus il y a d'objets, de couleurs ou de complexité, plus il est difficile d'effectuer manuellement toutes les opérations nécessaires pour produire un résultat final sans chevauchement.

Ce qu'il faut, c'est un moyen simple de modifier l'image de manière à ce que le résultat final ne soit constitué que des parties visibles des chemins, sans sections qui se chevauchent. Dans les programmes de graphisme matriciel, il s'agit d'une tâche courante pour combiner plusieurs couches en une seule, où l'on parle d'« aplatissement » des couches. Ainsi, avec Inkscape 1.3, nous avons maintenant Chemin > Aplatir pour obtenir le même effet avec les chemins. En sélectionnant les quatre chemins de cet exemple et en appliquant cette opération, on obtient les quatre objets suivants (éloignés les uns des autres et avec des traits ajoutés pour plus de clarté) :


**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.**

Pour une impression par écran ordinaire, cela conviendra parfaitement et représente un moyen beaucoup plus rapide de réaliser ce qui aurait été auparavant une série d'opérations booléennes fastidieuses et sujettes à erreurs.

L'autre nouvelle opération de tracé fait quelque chose de similaire, mais fragmente encore plus les éléments. Lorsque vous utilisez Chemin > Fracture, vous obtenez non seulement l'effet d'aplatissement, mais les formes qui se chevauchent sont encore plus fragmentées, comme si une opération Chemin > Division avait également eu lieu. Vous pouvez voir comment, dans cet exemple, il en résulte des chemins beaucoup plus individuels que l'opération d'aplatissement (encore une fois, les formes sont séparées et les traits sont ajoutés pour plus de clarté) :

Pour être honnête, je n'ai pas encore pensé à un bon exemple où aplatir et diviser les chemins de cette manière serait utile. Mais cela en dit peut-être plus sur mon manque d'imagination, car cette fonctionnalité pourrait bien être la chose que vous attendiez pour révolutionner votre flux de travail dans Inkscape.

Pendant que nous traitons des opérations booléennes, il y a un autre changement dans la version 1.3 qui doit être présenté : ce qui se passe quand vous utilisez Chemin > Objet en chemin avec un objet texte. Si vous avez une impression de déjà-vu, c'est parce qu'il s'agit d'un sujet qui a déjà été abordé dans cette série, car les développeurs d'Inkscape semblent insister pour modifier le comportement à quelques versions d'intervalle.


**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.**

Jusqu'à la version 0.47, cette opération convertissait simplement l'ensemble du contenu du texte en un seul chemin complexe. Il était donc extrêmement difficile de travailler avec les caractères individuels (techniquement, les glyphes), si tel était votre objectif. La version 0.48 a modifié le comportement pour créer un seul groupe composé d'un chemin par glyphe. Cela a rendu certaines tâches beaucoup plus faciles ; si vous ne vouliez vraiment qu'un seul chemin, l'utilisation de Chemin > Union plutôt que d'Objet en chemin permettait d'y parvenir sans avoir à dégrouper et à combiner des chemins séparés. Tout allait bien, jusqu'à ce que la version 1.0 casse l'astuce de Chemin > Union... mais les développeurs l'ont réparée une fois de plus dans la version 1.0.2 (voir la partie 100 de cette série pour plus de détails).

Ainsi, à part une brève période après la sortie de la version 1.0, cette fonctionnalité est restée assez stable : Chemin > Objet en chemin crée un groupe contenant un chemin par glyphe, tandis que Chemin > Union crée un chemin unique pour l'ensemble de l'objet texte. Tout le monde était content, et il n'y avait certainement, absolument, aucun besoin de bouleverser ce statu quo, n'est-ce pas ?

Apparemment, les développeurs d'Inkscape n'ont pas reçu le mémo, ou bien il existe une cabale secrète d'utilisateurs perturbateurs qui ne se sont jamais vraiment remis du changement de la v0.47, car la version 1.3 ramène les mauvais vieux jours où Objet en chemin créait un chemin unique pour l'ensemble du texte, sans option pour créer des chemins séparés pour chaque caractère. Mais attendez ! N'oubliez pas la chronique du mois dernier, dans laquelle j'ai examiné l'opération Chemin > Découper le chemin (Maj+Ctrl+Alt+K). Cela peut certainement vous aider. Enfin... peut-être. Parfois. En quelque sorte.


**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.**

Pour utiliser Chemin > Découper le chemin (Maj+Ctrl+Alt+K), vous devez d'abord avoir un chemin à diviser. Malheureusement, la conversion automatique d'un objet texte n'est pas possible, vous devez donc d'abord utiliser Chemin > Objet en chemin, puis suivre avec Chemin > Découper le chemin (Maj+Ctrl+Alt+K). Cependant, comme je l'ai noté le mois dernier, aussi utile que soit la fonction Découper le chemin (Maj+Ctrl+Alt+K), elle ne comprend pas que vous travaillez avec des glyphes. Le point au-dessus de chaque « i » et « j » devient un objet de chemin séparé, tout comme les accents sur les caractères ou les points au bas des points d'interrogation et d'exclamation. Si vous avez de la chance, vous pouvez vous en sortir en utilisant directement cette fonction, mais le plus souvent, un travail manuel supplémentaire est nécessaire pour recombiner les parties déconnectées de ces caractères.

Il existe une « solution » à ce problème qui devrait être présente dans la version 1.3.1 (qui sera probablement déjà sortie au moment où vous lirez ces lignes). Cette version ajoute une entrée de menu Texte > Text to Glyphs (texte vers glyphes), qui peut être utilisée pour diviser un objet texte en glyphes individuels avant d'utiliser Chemin > Objet en Chemin sur eux. Je l'ai essayé dans la version 1.3.1 Release Candidate, et cela fonctionne... mais cela ajoute une étape supplémentaire qui n'était pas nécessaire auparavant. Si vous êtes toujours sur la version 1.3, vous pouvez peut-être utiliser l'extension Texte > Diviser le texte (dans le menu Extensions) pour obtenir le même résultat - bien que mon expérience personnelle avec cela ait été extrêmement médiocre, les caractères fractionnés étant très mal placés.

En ce qui concerne les caractères mal placés, la nouvelle fonction Text to Glyphs déplace également votre texte si vous avez ajusté la position verticale ou la rotation de certains caractères.


**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.**

L'exemple ci-dessous montre les résultats de l'extension et de la nouvelle fonction. Le texte au milieu est l'original : j'ai délibérément utilisé deux polices, l'une d'entre elles ayant des graisses et des styles différents. J'ai également ajusté manuellement la hauteur verticale de certaines lettres et la rotation d'autres.

La ligne en haut est le résultat de l'utilisation de l'extension. Pour être clair, je ne l'ai pas déplacée à cet endroit - l'extension a décidé de placer le résultat en haut de la page, en ignorant la position de l'objet texte d'origine. Elle a fait du bon travail en préservant les polices, les graisses et les styles. Mais non seulement elle a ignoré les ajustements verticaux et la rotation, mais elle a aussi des idées très étranges sur l'espacement entre les caractères.

La ligne du bas montre le résultat de la fonction Text to Glyphs. Cette fois, le texte divisé est apparu au même endroit que l'original et je l'ai donc déplacé vers le bas. Vous pouvez constater que les polices, les graisses et les styles ont été préservés, mais que l'alignement vertical et la rotation ont, une fois de plus, été ignorés. Des deux, cependant, c'est certainement celui qui donne le meilleur résultat.


**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…?**

Comparons avec le comportement de la version 1.2.x. Dans ce cas, le texte original se trouve en haut et deux copies ont été faites et déplacées vers le bas pour que vous puissiez voir plus clairement le résultat de chaque opération. La deuxième ligne est le résultat de l'opération Chemin > Objet en chemin. Comme vous pouvez le constater, elle est identique à l'original en termes de style et de position. Mais en pratique, il s'agit maintenant d'un groupe de chemins individuels, un pour chaque glyphe. La troisième ligne montre le résultat de Chemin > Union, qui préserve à nouveau le style et la position, mais perd le changement de couleur dû à la création d'un seul chemin complexe pour l'ensemble du texte.

À mon avis, ce changement de comportement constitue un énorme pas en arrière. Il supprime totalement une fonctionnalité parfaitement fiable de la version 1.2 et la remplace par des options beaucoup moins fonctionnelles, mais il ne semble pas offrir de nouvelles possibilités qui justifient ce compromis. Si vous jouez avec l'alignement et la rotation des caractères individuels dans votre texte, la seule façon de créer un groupe de chemins à partir des glyphes soigneusement placés est maintenant d'utiliser Objet en chemin, puis Découper le chemin, puis d'arranger manuellement les caractères qui sont composés de plusieurs parties. Mais vous perdrez également tous les changements de couleur en cours de route et vous devrez les réappliquer manuellement. Cela transforme une opération en une seule étape en quelque chose de beaucoup plus complexe.

Je me demande dans combien de temps j'écrirai un article pour décrire une nouvelle modification de ce comportement... ?