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.
Dans les prochains articles, j'examinerai les nouveaux LPE (Live Path Effects - Effets de chemin interactifs, ECI) qui ont été ajoutés à Inkscape 1.0 et 1.1. Les articles précédents de cette série fournissent une introduction générale aux LPE et ce qu'ils sont (la partie 42), ainsi qu'une plongée plus profonde dans les LPE qui sont arrivés avec les versions précédentes d'Inkscape (les parties 42 à 47, 65 à 69). La partie précédente détaillait les changements assez généraux apportés à la boîte de dialogue LPE dans la version 1.0 ; mais ce mois-ci, je vais m'intéresser au premier des nouveaux LPE, ainsi qu'à un ancien LPE qui a connu une sorte de renaissance.
Contour en pointillé
À première vue, il ne semble pas y avoir de besoin évident pour un LPE qui rend le contour d'un objet sous forme de tirets. Après tout, la boîte de dialogue Fond et contour propose déjà divers motifs de tirets qui font partie du format SVG natif (rappelez-vous que les LPE sont une extension spécifique à Inkscape). Mais, bien que les tirets standard SVG soient souvent suffisants, ils manquent de nuance dans la façon dont ils sont distribués le long d'un chemin, ce qui peut donner un résultat peu esthétique. C'est le créneau que cette nouvelle LPE vise à aborder. Pour vous donner un exemple rapide, regardez ces étoiles avec contours, la rouge à gauche utilisant les tirets SVG standard, et la bleue à droite utilisant le LPE Contour en pointillé.
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.
Portez votre attention sur la façon dont les coins - concaves et convexes - sont rendus. La version SVG est symétrique par rapport à l'axe vertical, mais seulement parce que j'ai ajusté le décalage des tirets pour donner cet effet. Sans cette intervention manuelle, les tirets n'étaient pas du tout symétriques. Cependant, même avec ce changement, les coins diffèrent à mesure que l'on se déplace autour de l'étoile : pour les extrémités de la forme, nous aimerions probablement qu'elles ressemblent toutes au point du haut, et non aux quatre autres. Aucun des coins intérieurs ne correspond vraiment à ce que nous souhaitons dans la plupart des cas. Remarquez que la version LPE donne exactement le bon aspect, les coins étant tous agréablement similaires et symétriques.
Prenons un autre exemple. Les contours en pointillés sont couramment utilisés autour de simples boîtes rectangulaires dans les organigrammes et autres diagrammes. Selon vous, quelle est la meilleure version : la version SVG rouge (à gauche) ou la version LPE bleue (à droite) ? Une fois encore, concentrez-vous sur les coins.
La raison de cette différence est que la spécification SVG pour les traits utilise un algorithme très simple pour déterminer comment dessiner les lignes et les espaces. Elle commence simplement au début du chemin et dessine une série de tirets et d'espaces alternés, sur la base du modèle décrit dans l'attribut stroke-dasharray ou la propriété CSS. Elle ne se soucie pas des courbes ou des angles, elle se contente de rendre une série répétée de traits et d'espaces du début à la fin, quelle que soit la forme sous-jacente. Vous pouvez contrôler la position du premier tiret à l'aide de l'attribut ou de la propriété stroke-dashoffset (qui apparaît dans la boîte de dialogue Fond et contour d'Inkscape), mais cela ne fait que décaler l'ensemble du motif. Cela n'affecte pas la longueur de chaque trait ou espace, et vous risquez donc de vous retrouver avec des tirets déséquilibrés lorsqu'ils s'enroulent autour des coins de votre forme.
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.
Le LPE, quant à lui, fonctionne un peu différemment. Le plus grand changement est qu'il peut travailler individuellement sur chaque segment d'un chemin, plutôt que de traiter le chemin entier comme un seul tronçon à tracer en un seul trait. C'est le secret de ces coins plus beaux : dessiner un demi-tiret à chaque extrémité d'un segment permet d'obtenir des tirets agréablement symétriques au moment où le chemin prend un virage. Examinons les options disponibles de ce LPE, et les paramètres que j'ai utilisés pour le rectangle bleu.
Je vais décrire ces paramètres dans le désordre, car c'est la meilleure façon d'expliquer ce que fait chaque option. Je vais commencer par le paramètre « Appliquer aux segments » : lorsqu'il n'est pas coché, les autres paramètres s'appliquent à l'ensemble du chemin (comme les tirets natifs SVG). Lorsqu'il est coché, chaque segment d'un chemin est traité séparément. Dans la plupart des cas, vous voudrez probablement cocher cette case.
En reprenant en haut, le paramètre « Nombre de tirets » définit le nombre de tirets qui seront rendus sur toute la longueur du chemin, ou sur chaque segment individuel. Mais le nombre réel dépendra également de l'option « Equalize dashes » (Égaliser les pointillés), comme nous le verrons bientôt. Cependant, ce paramètre est au cœur de la différence fondamentale avec les tirets LPE : les tirets SVG n'ont pas de nombre ou de limite, ils continuent simplement à s'afficher tant qu'il reste un chemin à remplir ; les tirets LPE, en revanche, visent à faire tenir un nombre spécifique de tirets dans chaque chemin ou segment, en subdivisant la longueur disponible en fonction de ce paramètre, puis en distribuant les tirets et les espaces de manière égale.
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.
Les longueurs relatives des tirets et des espaces peuvent être ajustées à l'aide du « Facteur d'intervalle ». Laissez-le à zéro pour qu'ils aient la même taille, augmentez-le (jusqu'à +0,99999) pour augmenter la taille des tirets et réduire les espaces, ou diminuez-le (jusqu'à -0,99999) pour ajuster l'équilibre dans la direction opposée. En le réduisant à sa valeur la plus basse, chaque tiret n'est rien d'autre qu'une paire de terminaisons de ligne, comme défini dans la boîte de dialogue Fond et contour : un cercle (pour les terminaisons rondes) ou un carré (pour les carrées). Attention toutefois si vous utilisez le style « Terminaison sur le nœud », qui fait disparaître complètement les tirets au facteur d'intervalle le plus bas. Notez toutefois que l'utilisation de ce seul ratio signifie que la LPE ne peut pas produire tous les types de combinaisons de tirets et de points que le tableau de contours permet avec les contours SVG normaux.
Le paramètre « Demi-début/fin » détermine s'il faut dessiner les début et fin sous la forme d'une moitié de tiret seulement (coché) ou, si possible, dessiner un tiret complet au début et à la fin (non coché). Il est généralement préférable de laisser ce paramètre coché afin de bénéficier des avantages esthétiques de la symétrie et d'un espacement régulier. Chaque demi-tiret contribue toujours au compte du « Nombre de tirets », de sorte qu'un compte de 5 avec ce paramètre activé signifie en fait 3 tirets entiers et deux demi-tirets, plutôt que les 4 tirets entiers (plus deux moitiés) auxquels vous pourriez vous attendre si vous additionniez numériquement les morceaux.
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.
Enfin, le paramètre « Equalize dashes » (Égalisation des tirets) a le pouvoir de bouleverser complètement le compte du « Nombre de tirets ». Lorsque ce paramètre est coché, l'algorithme crée d'abord le nombre souhaité de tirets pour le segment le plus court du chemin. La longueur de chaque tiret de ce segment est ensuite utilisée pour le rendu de tous les autres segments, en en ajoutant plus que le nombre réel s'il y a de la place. Une démonstration peut rendre cela un peu plus clair.
Dans l'image ci-dessous, les deux chemins sont identiques, mais l'option « Equalize dashes » n'est pas cochée dans celui du haut, alors qu'elle l'est dans celui du bas. J'ai positionné quelques guides verticaux pour rendre plus claire la position des nœuds du chemin - c'est-à-dire là où commence et se termine chaque segment. Le chemin du haut respecte complètement le compte « Nombre de pointillés » : chaque segment a 5 tirets (3 entiers, 2 demi). Mais cela entraîne un espacement différent entre les tirets d'un segment à l'autre, et même des tirets de taille différente dans les deux segments du milieu où ils ont dû être comprimés dans un espace plus petit.
Le chemin du bas, en revanche, montre clairement que tous les tirets et espaces sont uniformes sur tous les segments. Mais cela se fait au détriment de la valeur « Nombre de pointillés ». Ce paramètre est utilisé lors du calcul du plus petit segment (le troisième), mais la taille des tirets et des espaces qui en résulte est simplement utilisée pour tous les autres segments, quel que soit leur nombre. Comme vous pouvez le constater, le résultat final est meilleur et correspond probablement à ce que vous souhaitez, mais le premier et le dernier segment comportent largement plus de 5 tirets chacun.
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.
Il y a une partie supplémentaire de l'interface utilisateur dans la capture d'écran de la boîte de dialogue LPE : pas un autre paramètre, mais une note dans une boîte, qui dit « Ajouter du remplissage avec l'effet « Remplir dans les nuées » ». Qu'est-ce que cela peut bien vouloir dire, et pourquoi est-ce nécessaire ?
Remplir dans les nuées
Rappelez-vous que la sortie d'un LPE est juste un chemin SVG ; donc toutes les choses intelligentes que les LPE peuvent faire doivent être rendues en utilisant les capacités normales de SVG. Comme nous l'avons déjà vu, le SVG brut ne peut pas produire le type de tirets que nous obtenons avec le LPE Contour en pointillé, alors que voyons-nous réellement dans le rendu de notre sortie ?
Le résultat est en fait un nouveau chemin complexe, composé d'un grand nombre de sous-chemins individuels, un pour chaque tiret visible. Si vous essayez d'ajouter un remplissage, vous ne remplirez que les sous-trajets, et non la forme entière. Comme la plupart des sous-chemins n'ont que deux nœuds, même ce remplissage n'est généralement pas visible. L'exception concerne les coins, où trois nœuds sont utilisés dans une configuration triangulaire. Bien sûr, l'ajout d'un remplissage à un chemin de type Contour en pointillé produit une toile de couleur dans les coins, mais pas la forme remplie que nous recherchons. À titre d'exemple, voici notre étoile de tout à l'heure, mais avec la largeur du trait réduite pour plus de clarté et en appliquant un remplissage orange.
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.
C'est un problème qui se pose depuis longtemps pour de nombreux LPE, et pas seulement pour le trait discontinu, et les développeurs d'Inkscape l'ont abordé de front il y a longtemps, en ajoutant le LPE « Remplir dans les nuées » dans la version 0.92. J'ai parlé de ce LPE en détail dans la partie 67 (le n° 127 de la FCM), bien que l'interface utilisateur se soit un peu développée depuis. Dans les anciennes versions, vous aviez seulement la possibilité d'ajouter des chemins au LPE, en signalant certains d'entre eux comme devant être inversés. La nouvelle interface utilisateur, lorsqu'elle est utilisée avec la même image de « Frankie» que dans la partie 67, ressemble à ceci.
La fonctionnalité de base reste la même : vous devez créer un chemin sacrificiel sur lequel appliquer ce LPE, puis ajouter chacun de vos chemins sources en les copiant dans le presse-papiers et en les ajoutant à la liste du LPE, comme décrit dans l'article cité. Ce processus peut s'avérer long et difficile lorsqu'il s'agit d'un grand nombre de chemins, bien qu'il ne soit pas trop difficile pour ajouter un remplissage à une forme avec le LPE Trait discontinu, car il n'y a qu'un seul chemin à ajouter dans ce cas-là. Voici les étapes nécessaires, par exemple, pour ajouter un remplissage à notre rectangle : - Dessinez un chemin sacrificiel (généralement une simple ligne à deux nœuds). - Ajoutez l'option Remplir dans les nuées au chemin sacrifié. - Sélectionnez la trajectoire à laquelle le LPE Trait en pointillé a été appliqué (le rectangle) et copiez-la dans le presse-papiers. - Re-sélectionnez le chemin sacrificiel afin de faire apparaître l'interface utilisateur du LPE Remplir dans les nuées. - Cliquez sur le bouton « Lier au chemin contenu dans le presse-papiers » pour ajouter à la liste le chemin avec trait pointillé. - Ajustez les valeurs de remplissage et de trait en fonction de vos besoins.
Avec un peu de chance, vous constaterez que votre rectangle a un remplissage, mais les choses ne se passent pas toujours aussi bien. Lors de mes propres expériences, j'ai essayé de suivre ces étapes avec une étoile plutôt qu'un rectangle, ce qui a eu pour résultat soit l'absence de remplissage, soit un objet de remplissage surdimensionné qui est mal positionné et ne peut pas être déplacé. Il y a certainement des bogues dans cette LPE qui n'ont pas encore été corrigés.
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.
Par rapport à la v0.92, la nouvelle version de ce LPE fournit également quelques paramètres supplémentaires à régler. Il y a une case à cocher « Visible » pour chaque chemin, vous permettant de le retirer temporairement de la forme remplie, peut-être pour tester si, oui ou non, il apporte quelque chose d'utile, avant de le retirer complètement de la liste. La case à cocher « Joindre les sous-chemins » vous permet de remplir chaque sous-chemin individuellement (non coché), ou d'utiliser l'ancien comportement consistant à joindre les sous-chemins pour créer une forme unique à remplir (coché). Cette dernière option est presque toujours celle que vous souhaitez. Une autre case à cocher (« Fermer ») vous permet maintenant de laisser le nouveau chemin non fermé entre le premier et le dernier chemin de la liste, probablement plus utile si vous utilisez ce LPE pour ajouter un trait supplémentaire plutôt qu'un remplissage et, encore une fois, quelque chose que vous voudrez généralement laisser coché. Enfin, l'option « Inversion automatique » remplace les cases à cocher individuelles « Inverser » de chaque chemin : si cette option est cochée, l'algorithme essaiera de joindre les chemins en fonction de la proximité de leurs extrémités, plutôt que de suivre strictement la direction de chaque chemin. En général, cette option donne de bons résultats et il est préférable de la laisser cochée, mais vous avez la possibilité de la désactiver et de gérer l'inversion des chemins sur une base individuelle, comme auparavant, si vous le souhaitez.
Le menu déroulant est également un nouvel ajout, choisissant comment les chemins de la source doivent être interprétés. En général, conserver « Avec Spiro ou BSpline » est une bonne option : cela utilisera essentiellement la forme que vous avez dessinée à l'origine, qu'elle ait été créée en utilisant des chemins SVG simples, ou que vous ayez utilisé les options Spiro ou BSpline qu'Inkscape expose dans certains outils de dessin. En pratique, ces options sont implémentées en tant que LPE, et cette option indique à Inkscape d'utiliser la sortie de ces LPE comme source, si elles existent, ou, sinon, d'utiliser simplement les données du chemin. Vous pouvez également sélectionner « Without all LPEs » pour utiliser uniquement les données de chemin d'origine, sans tenir compte des LPE appliqués. Inversement, l'option « With all LPEs » utilisera les données de trajectoire issues de toute série de LPE appliquée à la forme. Sachez que cela peut rapidement conduire à des formes très complexes si vous ne faites pas attention ; ce n'est donc pas souvent le choix que vous voudrez.
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.
Si l'on considère le nombre d'étapes nécessaires pour ajouter un remplissage à un chemin où le LPE « Contour en pointillé » est appliqué, on peut penser que l'effort supplémentaire et la confusion n'en valent pas la peine, et préférer s'en tenir aux tirets SVG ou dessiner le remplissage comme un objet séparé. Le LPE « Remplir dans les nuées » peut certainement être une fonctionnalité difficile à comprendre, et dans d'autres cas d'utilisation où vous devez ajouter plusieurs chemins à la boîte de dialogue, cela peut être une perte de temps. Heureusement, les développeurs d'Inkscape se sont rendu compte que cette complexité entrave l'utilisation d'une fonction autrement utile. Ainsi, avec la version 1.1, ils ont ajouté une nouvelle entrée de menu, Chemin > Remplir entre les chemins, qui créera silencieusement un chemin sacrifié et lui ajoutera le LPE « Remplir dans les nuées », déjà rempli de tous les chemins de votre dessin qui ont été sélectionnés à ce moment-là. Il est donc très facile d'utiliser ce LPE dans la plupart des cas : il suffit de sélectionner le ou les chemins qui doivent être remplis et de sélectionner l'option de menu. Vous pouvez ensuite sélectionner le remplissage nouvellement ajouté afin d'accéder aux paramètres du LPE si vous en avez besoin (par exemple, pour inverser des chemins spécifiques).
Notez que le chemin sacrificiel ajouté par Inkscape est de longueur nulle : son attribut « inkscape:original-d » consiste simplement en une commande « M 0,0 », qui ne dessine rien en réalité. En tant que tel, faites attention à ne pas masquer la visibilité du LPE, ou celle de tous ses chemins listés, sinon vous ne pourrez pas le sélectionner sur le canevas. Dans ce cas, vous devrez le trouver dans l'éditeur XML (recherchez un chemin avec la valeur « M 0,0 ») afin de le sélectionner pour le modifier ou le supprimer.
Cette nouvelle entrée de menu est un excellent ajout pour travailler avec les LPE, car elle permet de contourner l'un des problèmes les plus fondamentaux que la plupart des utilisateurs rencontrent lorsqu'ils commencent à les utiliser. Rien que pour cette raison, ça vaut la peine de passer à la version 1.1.x si vous ne l'avez pas encore fait. Il est bien dommage, cependant, que le LPE « Remplir dans les nuées », même lorsqu'il est ajouté à l'aide de cette entrée de menu, puisse encore être assez bogué, même pour des exemples simples. Espérons que les prochaines versions le rendront plus robuste, ce qui contribuera à faire des LPE en général un outil beaucoup plus utile qu'il ne l'est déjà.