issue177:inkscape
Différences
Ci-dessous, les différences entre deux révisions de la page.
| Prochaine révision | Révision précédente | ||
| issue177:inkscape [2022/01/29 14:40] – créée auntiee | issue177:inkscape [2022/01/31 17:33] (Version actuelle) – d52fr | ||
|---|---|---|---|
| Ligne 1: | Ligne 1: | ||
| - | 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. | + | **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 | 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. | + | 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. | + | Dans les prochains articles, j' |
| + | |||
| + | 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. | 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 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' | ||
| + | |||
| + | 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' | ||
| - | 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, | + | **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, |
| 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. | 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. | + | 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. | + | 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' |
| - | The “Half start/ | + | Je vais décrire ces paramètres dans le désordre, car c'est la meilleure façon d' |
| - | 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. | + | 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' |
| + | |||
| + | |||
| + | **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/ | ||
| + | |||
| + | Les longueurs relatives des tirets et des espaces peuvent être ajustées à l'aide du « Facteur d' | ||
| + | |||
| + | Le paramètre « Demi-début/ | ||
| + | |||
| + | |||
| + | **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. | 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. | + | 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? | + | 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' |
| + | |||
| + | Dans l' | ||
| + | |||
| + | 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), | ||
| + | |||
| + | |||
| + | **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 | Fill Between Many | ||
| Ligne 33: | Ligne 66: | ||
| 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? | 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. | + | 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. | + | Il y a une partie supplémentaire de l' |
| + | |||
| + | 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' | ||
| + | |||
| + | Le résultat est en fait un nouveau chemin complexe, composé d'un grand nombre de sous-chemins individuels, | ||
| + | |||
| + | |||
| + | **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: | 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: | ||
| Ligne 45: | Ligne 87: | ||
| • Adjust the fill and stroke values to suit your needs | • 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, | + | With luck you’ll now find that your rectangle has a fill, but things don’t always go so smoothly. In my own experiments, |
| - | 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 | + | C'est un problème qui se pose depuis longtemps pour de nombreux |
| - | 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” | + | 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' |
| + | - Dessinez un chemin sacrificiel (généralement une simple ligne à deux nœuds). | ||
| + | - Ajoutez l'option | ||
| + | - 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' | ||
| + | - 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. | ||
| - | 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). | + | Avec un peu de chance, vous constaterez que votre rectangle a un remplissage, |
| + | |||
| + | **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), | ||
| + | |||
| + | 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' | ||
| + | |||
| + | 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' | ||
| + | |||
| + | |||
| + | **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: | Note that the sacrificial path added by Inkscape is of zero length: its “inkscape: | ||
| - | 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. | + | 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' | ||
| + | |||
| + | Notez que le chemin sacrificiel ajouté par Inkscape est de longueur nulle : son attribut « inkscape: | ||
| + | |||
| + | 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' | ||
issue177/inkscape.1643463629.txt.gz · Dernière modification : 2022/01/29 14:40 de auntiee