1
After the previous instalment of this series had gone to press, an interesting problem was raised at www.inkscapeforum.com that directly relates to the use of unset fills and clones. So, before moving on to the next topic, I think it's worth drawing attention to this issue, and how you can deal with it. Let us suppose that you create a parent object and unset both its fill and stroke. As you know from the previous instalment, you can now set the fill and stroke on any clones independently. I demonstrated using colors, patterns and gradients for both the fill and the stroke, but it seems that one thing I missed was setting a non-opaque color – i.e. one with the alpha (A) channel in the Fill and Stroke dialog set to something other than 255. It turns out that doing this with the stroke works perfectly well, but the opacity of the fill color is completely ignored. In this example you can see what I mean. Both the fill and stroke opacities on the clone have been set to 177, but only the stroke actually appears transparent (the bottom diamond shows how the clone should appear). It turns out that there's a bit of a bug in Inkscape (issue 1183400 in Launchpad). When you unset a fill, the program fails to remove the “fill-opacity” attribute in the SVG. Any clones made from that object are then stuck with the opacity that the parent fill had before it was unset. As a demonstration of this, I created a clone and filled it with an opaque green color. Then I set the alpha channel for the green fill to 177. Next I unset the fill altogether. Finally I cloned the object and gave the clone a fully opaque purple color.
Le numéro précédent était déjà parti à l'impression quand un problème intéressant en rapport direct avec les remplissages et les contours indéfinis à été posté sur www.inkscapeforum.com. Aussi, avant de passer au sujet suivant, je pense que ça vaut le coup de se pencher sur ce défaut et de voir comment le traiter.
Supposons que vous ayez créé un objet parent et que ses remplissage et contour soient rendus indéfinis. Comme vous le savez depuis l'épisode précédent, vous pouvez définir le contour et le remplissage de chacun des clones de façon indépendante. Je l'ai démontré en utilisant des couleurs, des motifs et des gradients pour les contours et pour les remplissages, mais il semble que la seule chose j'ai oublié d'aborder était la définition d'une couleur non opaque - c'est-à-dire une dont le canal alpha (A) est réglé à une valeur différente de 255 dans la boîte de dialogue Remplissage et contour. Il s'avère que le faire pour le contour marche parfaitement bien, mais l'opacité de la couleur de remplissage est tout à fait ignorée. Dans cet exemple, vous pouvez voir ce que je veux dire. Les opacités du contour et du remplissage ont été réglées à 177, mais seul le tracé paraît transparent (le losange du bas montre à quoi le clone devrait ressembler).
Il semble qu'il y ait un petit bug dans Inkscape (erreur 1183400 dans Launchpad). Quand vous rendez un remplissage indéfini, le programme oublie de retirer l'attribut « fill-opacity » [opacité du remplissage] dans le moteur de dessin vectoriel SVG. Tous les clones issus de cet objet sont liés à l'opacité que le remplissage du parent avait avant de le rendre indéfini. Comme démonstration de ceci, j'ai créé un clone et je l'ai rempli avec une couleur verte opaque. Puis, j'ai réglé le canal alpha pour la couleur verte à 177. Ensuite, j'ai rendu entièrement indéfini le remplissage. Enfin, j'ai cloné l'objet et j'ai attribué au clone une couleur violette complètement opaque.
What I would expect to see here is that unsetting the fill should also unset the opacity, making it default to the SVG standard of fully opaque. Clearly the parent at the bottom is still translucent, as the blue bar behind it shows. Even without the blue bar, it appears as a washed out gray color, rather than the deep black we would usually expect of an unset fill. Furthermore, the clone is now forced to adopt the transparency of the parent, so there's no way that any clones of this object could be completely opaque, regardless of their own alpha value. For most people this bug may never be a problem, but if you do want to set the opacity of your clones to be anything other than 100%, there is a “fix” for the issue. It will mean using Inkscape's XML Editor dialog, which is a topic I had hoped to avoid until later in this series, but as my hand has been forced, I've decided to introduce it now. But to understand the XML editor, you first need a little insight into the structure of an Inkscape file.
Ce que je m'attendais à voir, c'est qu'en rendant le remplissage indéfini l'opacité soit aussi rendue indéfinie, la ramenant par défaut au standard SVG, entièrement opaque. Clairement, le parent du bas est toujours translucide, comme le montre la barre bleue à l'arrière-plan. Même sans la barre bleue, la couleur est grise délavée, au lieu du noir bien franc que nous attendrions d'un remplissage indéfini. De plus, le clone est lui aussi obligé d'adopter la transparence du parent ; il n'y a donc aucune possibilité qu'un clone de cet objet puisse être complètement opaque, quelle que soit sa propre valeur d'alpha.
Pour la plupart des gens, ce défaut ne sera sans doute jamais un problème, mais si vous voulez absolument régler l'opacité de vos clones à une autre valeur que 100 %, il y a une solution à ce défaut. Vous devrez utiliser la boîte de dialogue Édition XML d'Inkscape qui est un sujet que j’espérais n'aborder que tard dans cette série. Cependant, poussé par les événements, j'ai décidé de le présenter maintenant. Mais pour comprendre l'éditeur XML, vous avez d'abord besoin d'un petit aperçu de la structure d'un fichier Inkscape.
2
The SVG format that Inkscape natively uses is an XML file, meaning that it follows the rules, conventions and structure for such files as defined by the W3C – the standards body of the web. XML is a dubious abbreviation of “eXtensible Markup Language”. In short, it means that every Inkscape file is made up of a hierarchical collection of “tags” (also called “elements” or “nodes”), each of which can carry “attributes” to further define it. For example a simple rectangle might appear in an SVG document as a “rect” tag, with attributes for defining its size and location: <rect height=“300” width=“400” x=“50” y=“100” /> What about the hierarchical aspect I mentioned? How about this more complex example: <svg xmlns=“http://www.w3.org/2000/svg”> <g> <rect id=“r1” height=“300” width=“400” x=“50” y=“100” fill=“red” /> <rect id=“r2” height=“500” width=“100” x=“200” y=“50” fill=“blue” /> </g> </svg> As you can see, we've got two rectangles now, and they've gained a couple more attributes to set the fill color, and to give each of them an ID so we can identify them individually. Those are both inside a set of <g>…</g> tags, which defines a group in SVG terms. The group, in turn, is inside the outermost pair of <svg>…</svg> tags. You can think of these as a clue to an application that the content inside them should be rendered as SVG, rather than as HTML or plain text.
Le format SVG qu'Inkscape utilise nativement est un fichier XML, ce qui signifie qu'il suit les règles, conventions et structure de tels fichiers comme l'a défini le W3C - l'organisme des normes du Web. XML est l’abréviation biaisée de « eXtensible Markup Language » [Ndt : langage de balisage extensible - Wikipedia.] En bref, ça signifie que chaque fichier Inkscape est constitué d'un ensemble hiérarchisé de « balises » [tag] (appelées aussi « éléments » [element] ou « nœuds » [node]), chacun d'eux pouvant porter des « attributs » [attribute] pour le définir plus complètement. Par exemple, un simple rectangle peut apparaître dans un document SVG comme une balise « rect », avec des attributs qui définissent sa taille et sa position :
<rect height=“300” width=“400” x=“50” y=“100” />
Et à propos de l'aspect hiérarchisé que j'ai mentionné ? Voici un exemple plus complet :
<svg xmlns=“http://www.w3.org/2000/svg”>
<g>
<rect id="r1" height="300" width="400" x="50" y="100" fill="red" />
<rect id="r2" height="500" width="100" x="200" y="50" fill="blue" />
</g>
</svg>
Comme vous pouvez le voir, ici nous avons deux rectangles avec deux attributs supplémentaires pour indiquer la couleur de remplissage et pour donner à chacun un identifiant qui les repère individuellement. Ceux-ci sont à l'intérieur d'un jeu de balises <g>…</g>, qui définit un groupe dans le vocabulaire SVG. A son tour, le groupe est à l'intérieur d'une paire de balises de niveau supérieur <svg>…</svg>. Vous pouvez considérer ces informations comme une indication pour une application que le contenu entre ces balises devra être rendu comme du SVG, plutôt que comme du HTML ou du texte brut.
Because the “r1” rectangle is first in the file, it's drawn first on the canvas. The “r2” rectangle is drawn afterwards, so it overlaps the first one. The result is a simple SVG image with a blue rectangle on top of a red one, both inside a group. Try it for yourself: copy the code above into a text editor and save it with an “svg” extension, then load the file into a web browser or Inkscape. What if we wanted another rectangle, outside the group? We could just include an additional <rect> element but place it after the opening <svg> tag but before the opening <g> tag. That would put it behind the group when the image is rendered. Place it after the closing </g> tag, and before the closing </svg> tag, and it will appear on top of the group. Give it a try for yourself, but remember to change the position, size and colour of the new rectangle so that it doesn't get obscured by the existing ones. While you're editing the file, how about adding “rx” and “ry” attributes to set the size of the corner radius. Or replace the <rect> with a <circle>, swapping the dimension and position attributes for “cx”, “cy” and “r” to set the center coordinates and the radius.
Parce que le rectangle « r1 » est le premier de la liste, il est dessiné en premier sur le canevas. Le rectangle « r2 » est dessiné ensuite, et les deux se chevauchent. Le résultat est une simple image SVG avec un rectangle bleu sur un rectangle rouge, tous les deux dans un groupe. Essayez vous-même : copiez le code ci-dessus dans un éditeur de texte et sauvez-le dans un fichier avec l'extension « .svg », lancez-le ensuite dans votre navigateur Web ou dans Inkscape.
Que faire si nous voulons un autre rectangle, à l'extérieur du groupe ? Nous pouvons simplement ajouter un élément supplémentaire, mais en le plaçant après la balise ouvrante <svg> et avant la balise ouvrante <g>. Cela le placera derrière le groupe quand l'image est rendue. Placez-le après la balise fermante </g> et avant la balise fermante </svg> et il apparaîtra au-dessus du groupe. Faites l'essai vous-même, mais rappelez-vous de changer la taille, la position et la couleur du nouveau rectangle pour qu'il ne soit pas masqué par les anciens. Pendant que vous éditez le fichier, pourquoi pas ajouter des attributs « rx » et « ry » pour définir le rayon de courbure des angles ? Ou remplacer le <rect> par <circle> [un cercle], en remplaçant les attributs de position et de dimension par « cx », « cy » et « r » qui définissent les coordonnées du centre et le rayon ?
3
By now you should be starting to get a feel for the structure of an SVG document. Of course the ones that Inkscape produces are far more complex, generally including many more elements and attributes, but the basics remain the same. If you want to take a look at some more simple files in your text editor then I recommend the various flag images on Wikipedia, which tend to be pared down and minimised by hand, removing any unnecessary structure or metadata. Examining a few of these will quickly give you some insight into the structure of XML files. Let's switch back to Inkscape now, and create a very basic drawing – just a single purple rectangle on the canvas. With your new found knowledge of SVG you should know how to hand-code this in just three lines, yet, when I saved my copy from Inkscape, the resultant file had 62 lines in! Admittedly many of these were due to it putting every attribute onto its own line – an option that can be set in the SVG Output pane of the Inkscape Preferences dialog. Yet, even enabling the “Inline attributes” setting still resulted in 19 lines. What's going on?
A ce stade, devriez commencer à avoir une idée de la structure d'un document SVG. Bien sûr, ceux que produit Inkscape sont autrement plus compliqués, en général avec de nombreux éléments et attributs, mais les bases restent les mêmes. Si vous voulez jeter un œil à des fichiers plus simples avec votre éditeur de texte, je vous recommande alors les images variées de drapeaux dans Wikipedia, qui semblent avoir été réduites manuellement au strict minimum, en éliminant toutes les structures et métadonnées inutiles. Vous allez avoir rapidement un aperçu de la structure des fichiers XML en en examinant quelques-uns.
Revenons maintenant à Inkscape, pour créer un dessin très simple - juste un unique rectangle violet sur le canevas.
Avec vos nouvelles connaissances de SVG, vous devriez savoir comment coder ceci manuellement en trois lignes, alors que, quand je sauve mon dessin depuis Inkscape, le fichier résultant comprend 62 lignes ! J'avoue qu'une bonne partie de celles-ci sont dues à ce que les attributs sont placés sur des lignes séparées - une option qui peut être définie dans le volet Sortie SVG de la boîte de dialogue Préférences d'Inkscape. Cependant, même en cochant le paramètre « Attributs en ligne », il reste encore 19 lignes. Qu'est-ce qui se passe ?
Look at an Inkscape SVG file in a text editor and you'll quickly spot a lot of attributes that have a prefix to their names. So rather than label=“Layer 1” you'll see inkscape:label=“Layer 1”. This is a feature of XML called “namespaces”, and it's basically a mechanism by which one XML file can safely include elements and attributes from other XML languages without having to worry about them clashing. In this case it indicates that the “label” attribute isn't part of the SVG spec, but is rather an attribute from the “inkscape” namespace. This allows Inkscape to include application-specific data in a file, whilst still remaining compatible with the SVG specification, and therefore with other applications that can read SVG files (though they'll usually ignore the Inkscape-specific additions). In an Inkscape file, you'll typically see “inkscape” and “sodipodi” namespaces that are used to store application-specific data (Inkscape was created as a fork of an older SVG editor called Sodipodi – which was, itself, a fork of an even older vector graphics program). You'll also see “dc” which stands for Dublin Core, and represents the namespace for a set of defined terms used to contain metadata about the file. You can set these using the File > Document Metadata menu item in Inkscape, and it's recommended to fill out at least some of the fields if you plan to distribute your SVG file online. Because the metadata are stored in a standard form using a well known namespace, it increases the chance that your document could one day be indexed by online search engines.
Ouvrez le fichier SVG d'Inksape dans un éditeur de texte et vous allez rapidement découvrir que beaucoup d'attributs ont leur nom préfixé. Aussi, plutôt que label=“Layer 1” vous verrez inkscape:label=“Layer 1”. C'est une caractéristique de XML appelée « espace de noms » [namespaces] et c'est en gros un mécanisme permettant d'inclure dans un fichier XML des éléments et des attributs d'autres langages XML sans craindre les conflits. Dans ce cas-ci, cela indique que l'attribut « label » n'appartient pas à la spécification SVG, mais qu'il est au contraire un attribut de l'espace de noms « inkscape ». Ceci permet à Inkscape d'inclure des données propres à l'application dans un fichier, tout en restant compatible avec la spécif. SVG et, au-delà, avec les autres applications qui peuvent lire les fichiers SVG (bien qu'ils ignorent en général les additions propres à Inkscape).
Dans un fichier Inkscape, vous verrez typiquement des espaces de noms « inkscape » et « sodipodi » qui sont utilisés pour stocker les données propres à l'application (Inkscape a été créé comme fork d'un ancien éditeur SVG nommé Sodipodi - qui était lui-même un fork d'un programme de dessin vectoriel encore plus ancien). Vous verrez aussi « dc » qui veut dire Dublin Core et représente l'espace de noms pour un ensemble de termes définis utilisés pour contenir des métadonnées à propos du fichier. Vous pouvez définir ceux-ci dans Inkscape en utilisant la ligne du menu Fichier > Metadonnées du document et il est recommandé de remplir au moins quelques-uns de ces champs si vous prévoyez de distribuer votre fichier SVG sur internet. Parce que les métadonnées sont stockées sous une forme standard utilisant un espace de noms bien connu, ça augmente vos chances de voir votre document indexé un jour par les moteurs de recherche en ligne.
4
*One final thing to note in the file is that the rectangle itself, although it's pure SVG with no namespaced attributes, is a little different to the ones we created earlier. Whereas we used the fill=“red” syntax to provide a fill color, Inkscape uses a more general purpose “style” attribute to carry numerous details about the color and style of the rectangle. It also uses hexadecimal RGB numbers for the color, rather than a color name – you can force it to use color names where possible in the Inkscape Preferences, but it's usually not worth bothering with unless you have a specific reason to do so: most colors don't have corresponding names so will still be stored as hex numbers, and using names can cause problems with some Inkscape extensions. With all that background in place, it's finally time to look at the file in Inkscape's XML editor. You can open this by pressing CTRL-SHIFT-X or by selecting Edit > XML Editor from the menu bar. The dialog is made up primarily of a tree on the left which shows the structure of the SVG file, and a pane on the right to list and edit the selected item's attributes. The little triangles in the tree can be toggled to show or hide that particular part, and indentation is used to show the hierarchy of the elements. In this screenshot I've expanded all the triangles so that the metadata elements are visible, with their Dublin Core namespace. Despite the closing tags not being explicitly shown, you can nevertheless see that the rect at the bottom is “inside” the group (g) just above it – actually an Inkscape layer, as you can tell from the Inkscape-namespaced “label” attribute. This layer is, in turn, inside the root svg element. One thing to note is that the XML Editor shows the SVG namespace on elements (so you can see svg:svg, svg:g, svg:rect…) even though the exported file just uses the base names (in XML terms the SVG namespace is set as the default for the document, so it doesn't then need to be explicitly added to every element).
Une dernière chose à noter dans ce fichier : le rectangle lui-même, qui, bien qu'étant du pur SVG sans préfixe d'espace de noms, est un peu différent de ceux que nous avons créés précédemment. Alors que nous avions utilisé la syntaxe fill=“red” pour définir la couleur de remplissage, Inkscape utilise un attribut d'usage général « style » pour contenir les différents détails de couleur et de style du rectangle. Il utilise aussi une notation hexadécimale RGB pour la couleur plutôt qu'un nom de couleur - vous pouvez forcer l'utilisation des noms de couleurs dans les Préférences d'Inkscape mais ça n'en vaut pas la peine sauf si vous avez une raison précise pour le faire : la plupart des couleurs n'ont pas de correspondance de nom ; elles seront donc stockées en nombres hexa et l'utilisation de noms peut créer des problèmes avec quelques extensions d'Inkscape.
Après toute cette préparation, il est enfin temps de regarder le fichier dans l'éditeur XML d'Inkscape. Vous pouvez l'ouvrir avec les touches CTRL-MAJ-X ou en choisissant Édition > Éditeur XML… dans la barre de menu. À l'ouverture, la boîte de dialogue comporte surtout dans le volet gauche une arborescence qui représente la structure du fichier SVG, et un volet à droite pour lister et éditer les attributs sélectionnés. Les petits triangles dans l'arborescence peuvent être basculés pour montrer ou cacher un sous-ensemble et l'indentation est utilisée pour montrer la hiérarchisation des éléments. Dans cette copie d'écran, j'ai ouvert tous les triangles de sorte que les éléments de métadonnées soient visibles, avec leur espace de noms Dublin Core. Bien que les balises fermantes ne soient pas explicitement visibles, vous pouvez cependant voir que le rectangle en bas est à l'intérieur du groupe (g) juste au-dessus de lui - en fait, une couche Inkscape, comme vous pouvez le voir sur l'attribut « label » avec l'espace de noms Inkscape. Cette couche est à son tour à l'intérieur de l'élément svg racine. Notons que l'éditeur XML montre l'espace de noms SVG sur les éléments (ainsi nous pouvons lire : svg:svg, svg:g, svg:rect…), même si le fichier exporté utilise seulement les noms de base (en termes XML, l'espace de noms SVG est défini par défaut pour le document, aussi, il n'y a pas besoin de l'ajouter explicitement à chaque élément).
When an entry in the tree is highlighted, its attributes are shown on the right. If a single element or group is selected on the canvas it will be automatically selected in the XML Editor, so you can simply leave the dialog open and click on various objects in your drawing to see their details. Equally, selecting an entry in the tree will also select the corresponding object on the canvas. Here I have the rectangle selected, but there's something odd going on. If you look back at the image of the rectangle on the canvas you'll see that it has dimensions of 400×300 pixels, and is positioned at x=140, y=500. Now look at the XML Editor image: width, height and x are all correct, but y claims to be 252.36218 – which is pretty far from 500! SVG places its origin point at the top left of the document. This sort of makes sense, given that it comes from the world of the web where the height and width of a document can change dramatically, but the top left is always the top left. The x-axis therefore runs from left to right, as you might expect, but the y-axis runs from top to bottom, with positive values moving further down the page. Inkscape, on the other hand, presents a more traditional drawing view, with the origin in the bottom left, and the y-axis running up the page from top to bottom. So the 500 value you see in the main Inkscape window represents the distance from the bottom of the page to the bottom of the rectangle, whereas the value in the XML Editor (and the value that appears in the SVG file) is the distance from the top of the page to the top of the rectangle. Usually this incongruity has little impact, but if you're trying to find specific coordinates in an SVG image you do need to be aware of the difference.
Quand une entrée de l'arborescence est surlignée, ces attributs sont affichés à droite. Si un élément seul ou un groupe est sélectionné sur le canevas, il est automatiquement sélectionné dans l'éditeur XML ; vous pouvez donc laisser l'éditeur ouvert et cliquer sur les divers objets sur le canevas pour en voir les détails. De même, en sélectionnant une ligne de l'arborescence, l'objet correspondant sera sélectionné sur le canevas.
Ici, le rectangle est sélectionné, mais il y a quelque chose qui ne va pas. Si vous revenez à l'image du rectangle sur le canevas, vous verrez que ses dimensions sont de 400×300 pixels, et qu'il est positionné à x=140, y=500. Maintenant, regardez l'image dans l'éditeur XML : largeur, hauteur et x sont corrects, mais y affirme être à 252.3621 - ce qui est sacrément loin de 500 !
SVG place son point d'origine à l'angle en haut à gauche du document. Ceci est assez logique étant donné que dans le monde du Web la hauteur et la largeur d'un document peuvent changer énormément, mais l'angle en haut à gauche est toujours en haut à gauche. L'axe x augmente de gauche à droite, comme on peut s'y attendre, mais l'axe y augmente du haut vers le bas de la page. Inkscape, à l'inverse, présente une vision du dessin plus traditionnelle, avec une origine en bas à gauche et l'axe des y augmentant du bas vers le haut de la page. Ainsi, la valeur 500 que nous voyons dans la fenêtre principale d'Inkscape représente la distance du bas de la page jusqu'au bas du rectangle, alors que la valeur dans l'éditeur XML (et la valeur qui est visible dans le fichier SVG) est la distance du haut de la page jusqu'au haut du rectangle. Habituellement cette incongruité a peu d'impact, mais si vous essayez de trouver des coordonnées précises dans une image SVG, vous devrez être informé de cette différence.
5
With the rectangle still selected, let's click on the “style” attribute on the right. The attribute name and value is put into the fields at the bottom of the dialog. In the case of the style attribute, the value is actually a single long string which is, itself, made up of name:value pairs. If you're familiar with CSS from the web world, then you'll recognise the format – if not all of the property names (SVG uses a lot of the standard CSS properties you might know from writing HTML, but adds a few of its own). With the style attribute loaded for editing, we can now address that pesky issue with the fill-opacity and clones. See the “fill-opacity:1;” section, right near the start? We need to remove that. This is just a multiline text field, so simply click to place the cursor in there, then move around with the arrow keys and edit the text as you would normally. Once your editing is done, you need to click on the “Set” button to make it take effect. Assuming the fill-opacity's value was 1, then you shouldn't notice any change, since 1 in here corresponds to 255 in the Fill and Stroke dialog, and is the default for SVG if it's not specified.
Le rectangle étant toujours sélectionné, cliquons sur l'attribut « style » à droite. Le nom de l'attribut et sa valeur sont mis dans le champ en bas à droite de la boîte de dialogue. Dans le cas de l'attribut style, la valeur est une seule longue chaîne de caractères qui est elle-même composée de doublets nom:valeur. Si vous êtes à l'aise avec le CSS du monde de l'internet, alors vous reconnaîtrez le format - sinon la totalité des noms des propriétés (SVG utilise beaucoup de propriétés standard CSS que vous auriez pu rencontrer en écrivant du HTML, mais en ajoute quelques-unes). L'attribut style étant sélectionné pour l'édition, vous pouvez maintenant régler ce défaut agaçant sur l'opacité du remplissage avec les clones.
Vous voyez la section « fill-opacity:1 », juste à droite après le début ? Nous devons l'enlever. Comme ce n'est qu'un texte multi-lignes, cliquez simplement pour positionner le curseur dedans, puis déplacez-le avec les touches fléchées et modifiez le texte comme vous le feriez normalement. Une fois le texte modifié, vous devez cliquer sur le bouton « Définir » pour qu'il soit pris en compte. Comme la valeur de fill-opacity était égale à 1, vous ne devriez pas voir de différence, puisque 1 correspond à 255 dans la boîte de dialogue Remplissage et contour ; c'est la valeur par défaut de SVG quand elle n'est pas spécifiée.
Now clone the rectangle, and try changing the clone's color. You can't, of course, since the parent rectangle's fill is still purple, not unset – but, once you give the clone a fill color, you gain access to the alpha slider in the Fill and Stroke dialog. Reduce that value and you'll see that you can affect the transparency of the fill, if not its color. Select the parent again (SHIFT-D if the clone is still selected) and then unset the fill. Now you can change the clone's fill color and opacity to your heart's content. It's as simple as that: to work around this Inkscape bug, and restore the ability to change a clone's fill opacity independently of its parent, you just have to remove the fill-opacity property from the parent's style attribute. Doing this on my original test image gives exactly the result you would expect. You may have noticed that I haven't talked about the toolbars in the XML Editor, and that's with good reason. The buttons there give you the ability to significantly change the structure of your SVG file – potentially with disastrous effects if you're not sure what you're doing. By all means have a play around in the XML Editor. Move nodes, un-indent them, change their attributes or remove them altogether. It offers a fascinating insight into the structure of an Inkscape file, and gives you unprecedented power to tweak things that aren't always exposed in the Inkscape user interface. But if you do decide to experiment, please make sure you do it on a temporary file, or one you've got backed up elsewhere.
Maintenant, clonez le rectangle et essayez de changer sa couleur. Vous ne pouvez pas le faire, bien sûr, puisque le parent est encore violet, non rendu indéfini, mais une fois que vous avez donné une couleur de remplissage au clone, vous avez accès à la réglette alpha dans la boîte de dialogue Remplissage et contour. Réduisez cette valeur et vous allez voir l'effet sur la transparence du remplissage, sinon sur sa couleur. Sélectionnez le parent à nouveau (MAJ-D si le clone est encore sélectionné) et rendre le remplissage indéfini. Maintenant, vous pouvez changer la couleur de remplissage du clone et l'opacité comme vous voulez. C'est aussi simple que ça : pour contourner un défaut d'Inkscape et retrouver la possibilité de modifier l'opacité du remplissage d'un clone indépendamment de son parent, vous n'avez qu'à supprimer la propriété fill-opacity dans l'attribut style du parent. En le faisant sur mon image test d'origine j'obtiens exactement le résultat escompté.
Vous pouvez remarquer que je n'ai rien dit de la barre d'outils de l'éditeur XML et ceci pour une bonne raison. Ces boutons vous donnent la possibilité de modifier fortement la structure de votre fichier SVG - avec probablement des effets désastreux si vous ne savez pas trop ce que vous faites. De toutes les façons, faites des essais dans l'éditeur XML. Bougez les nœuds, supprimez une indentation, modifiez leurs attributs ou supprimez-les complètement. Cela vous donnera un aperçu passionnant de la structure d'un fichier Inkscape et vous aurez le pouvoir sans précédent de corriger des choses qui ne sont pas visibles dans l'interface utilisateur d'Inkscape. Mais si vous décidez de tenter l'expérience, assurez-vous, s'il vous plaît, de la faire dans un fichier temporaire ou un dont vous avez une sauvegarde quelque part.