I'm going to take a slight departure from the usual format for the first part of this month's article – and talk about politics. Not Trump, Brexit or the rise of populism, but rather the politics of open formats and browsers. First, a very brief (and simplified) history lesson: SVG, the file format used by Inkscape, was created under the auspices of the World Wide Web Consortium (W3C) – the organisation that was also charged with creating the specifications for HTML and CSS. HTML was already an established language, but loosely defined, and with a host of differences between the various browser implementations. The W3C tidied things up, but ultimately decided that the best way to get everyone writing good, cross-browser HTML was to effectively abandon the undisciplined language it had become, and move to a rigorously defined and structured alternative, XHTML. This was also part of a larger plan to promote XML, which can be thought of as a language for defining languages. XHTML was HTML re-cast as an XML language, bringing with it more scope for interoperability with other XML languages, including SVG.

Je vais m'éloigner légèrement du format habituel dans la première partie de l'article du mois pour parler de politique. Pas de Trump, du Brexit ou de la montée du populisme, mais plutôt de la politique des formats et navigateurs ouverts.

D'abord, un rappel historique bref (et simplifié) : SVG, le format de fichier utilisé par Inkscape, a été créé sous les auspices du World Wide Web Consortium (W3C - consortium pour un grand Internet mondial) - l'organisation qui était aussi en charge de créer les spécifications du HTML et de CSS. HTML était déjà un langage établi, mais défini approximativement, et avec de grandes différences d'implémentation entre les navigateurs. Le W3C a resserré les choses, mais, au final, a décidé que la meilleure façon pour que chacun puisse écrire du bon HTML multi-navigateurs était d'abandonner le langage indiscipliné qu'il est devenu et passer à une alternative définie plus rigoureusement et mieux structurée, le XHTML. Cela faisait partie aussi d'un plan plus vaste pour promouvoir le XML, qui peut être vu comme un langage pour définir des langages. XHTML était du HTML reformaté en langage XML, ce qui lui donnait plus d'ouverture pour une interopérabilité avec d'autres langages XML, dont le SVG.

As academically pure as the aims of XHTML were, they fell down in the real world. HTML had thrived partly because it was so lax. Browsers would do their best to interpret even the most malformed syntax, which greatly lowered the barrier to entry for non-programmers to create their own web pages. Lowering it further still were applications such as Dreamweaver and HoTMetaL, which would allow users to create web pages as easily as they would a Word document. HTML continued to proliferate online, and it would have been commercial suicide for any browser to render only XHTML. For all its purity and technical superiority, XHTML inevitably lost out to the looser standard, and the W3C's work became largely irrelevant. It was clear that the approach of having a standards body to write the specs, and only then for the browsers to implement them, was not one that would work in practice. What followed was a period of stagnation for the web. No browser wanted to introduce any radically new syntax into HTML or CSS for fear of re-kindling the bad old days of proprietary extensions. But eventually, the browser companies began to talk amongst themselves about ways to push the web forward again. The result was the formation of another standards body, WHATWG, whose remit was to improve the old HTML specs largely by documenting what the browsers already did, making it easier for all the vendors to bring their programs up to the same level of compliance. They also added a few new features to HTML, branding it as “HTML5”, although we're now several years on and many of their more useful ideas still haven't been universally implemented (how are those date and time pickers coming along, Mozilla?).

Pour aussi pures académiquement que pouvaient être les objectifs du XHTML, ils n'ont pas réussi dans le monde réel. HTML a prospéré en partie parce qu'il était laxiste. Les navigateurs faisaient de leur mieux pour interpréter la majorité de la syntaxe même quand elle était très mal ficelée, ce qui a grandement facilité la création de pages Web par des non programmateurs. Des applications comme Dreamweaver ou HoTMetal l'ont rendue encore plus facile, car elles permettaient aux utilisateurs de créer des pages Web aussi facilement qu'un document Word. HTML a continué à proliférer sur la toile et tout navigateur qui n'acceptait que le XHTML commettrait un suicide commercial. Du fait de sa pureté et de sa supériorité technique, XHTML a été inévitablement désavantagé face au standard moins poussé et le travail du W3C est devenu largement hors de propos. Il était clair qu'avoir un organisme normatif pour écrire les spécifications et, seulement ensuite, les implémenter dans les navigateurs, ne fonctionnait pas du tout.

Il s'en est suivi une période de stagnation pour le Web. Aucun navigateur ne voulait introduire une syntaxe radicalement nouvelle dans le HTML ou le CSS de peur de réactiver l'époque sombre des extensions propriétaires. Mais, finalement, les entreprises des navigateurs commencèrent à discuter entre elles sur les manières de relancer le Web. Le résultat fut la formation d'un autre organisme normatif, WHATWG, dont le mandat était d'améliorer les vieilles spécifs. HTML principalement en documentant ce que les navigateurs faisaient déjà, rendant plus facile, pour tous les fournisseurs, la mise à un même niveau de conformité de leurs programmes. Ils ajoutèrent aussi quelques fonctionnalités nouvelles au HTML, sous l'étiquette « HTML5 », bien que plusieurs années plus tard, beaucoup de leurs idées les plus utiles n'aient pas encore été implémentées par tous (quand arriveront ces sélecteurs de date et d'heure, Mozilla ?).

Eventually the W3C gave up on their philosophical march towards XHTML purity, and embraced the work of WHATWG, such that the HTML standard is now nominally back in their hands. But structurally, things have changed: no longer can the W3C write specs and expect browsers to implement them; now the browser vendors agree what to implement amongst themselves, and then the specification is written to match the implementations. Okay, in practice it's more nuanced than that, but the key point is that, these days, specs are largely driven by what browsers are prepared to implement. This has an impact on Inkscape because, as an SVG editor, its feature set follows the capabilities written into the SVG specification. But the SVG spec, in practice, can't gain any new capabilities without support from the browser vendors. Yet those vendors are loath to implement many of the new features, given that there are barely any files online that use them. Users, meanwhile, are equally loath to create content using these new features because no browser supports them. The authoring tools (such as Inkscape) would like to implement them, but, without browser support, the spec is unlikely to be finalised and supported – so any work they do could be rendered obsolete if the specification changes.

En définitive, le W3C a renoncé à sa marche philosophique vers la pureté du XHTML, et a accueilli le travail du WHATWG, de sorte que la norme HTML est maintenant revenue dans son giron. Mais, structurellement, les choses ont changé : fini le temps où le W3C écrivait les spécifs., espérant ensuite que les navigateurs les implémentent. Maintenant, les fournisseurs de navigateurs s'accordent sur ce qui sera implémenté, puis la spécification est écrite pour s'accorder à leurs implémentations. Bon ! D'accord ! En pratique, c'est un peu plus nuancé que ça, mais le point-clé est que, aujourd'hui, les spécifs. sont largement influencées par ce que les fournisseurs sont prêts à implémenter.

Ceci a un impact sur Inkscape, car, en tant qu'éditeur SVG, son ensemble de fonctionnalités suit les possibilités écrites dans la spécification SVG. Mais la spécif. SVG, en pratique, ne peut pas disposer des nouvelles capacités sans le support des fournisseurs de navigateurs. À nouveau, ces fournisseurs répugnent à implémenter beaucoup de fonctionnalités nouvelles, étant donné qu'il n'y a à peu près aucun fichier en ligne pour les utiliser. Dans le même temps, les utilisateurs ne sont pas plus pressés de créer du contenu utilisant les nouvelles fonctionnalités, car aucun navigateur ne les prend en charge. Les outils de création (comme Inkscape) aimeraient les implémenter, mais, sans le support des navigateurs, la spécif. a peu de chance d'être finalisée et supportée - de sorte que tout travail fait pourrait devenir obsolète si la spécification changeait.

And so we go round in circles: no files using the new features online means no browser support; no browser support means the specs don't stabilise; unstable specs make authoring tools less likely to support the features; no support in authoring tools makes users less likely to create and post files that use the new features; no files using the new features online means no browser support… and so on. To be fair, some limited support for new SVG features has made it into browsers – but mostly in areas where the SVG Working Group has relinquished ownership in order to move the feature to CSS. This is both good and bad news: CSS is one of the cornerstones of the web, so adding features there, rather than in SVG, makes them more likely to be adopted by browsers; conversely it further weakens the position of SVG as a stand-alone format, and requires non-browser applications to comply with standards that often don't sit easily outside the web environment, diminishing SVG's position as an independent file format.

Et on tourne en rond : pas de fichier utilisant les nouvelles fonctionnalités en ligne signifie pas de support des navigateurs ; aucun support des navigateurs entraîne qu'aucune spécif. ne se stabilise ; des spécifs instables découragent leur adoption par les outils de création ; l'absence d'adoption dans les outils de création freine le création et la diffusion en ligne des fichiers qui utilisent les nouvelles fonctionnalités ; sans fichiers en ligne utilisant ces nouvelles fonctions, pas de support des navigateurs… et ainsi de suite.

Par souci de justice, je dois dire qu'un support limité de nouvelles fonctionnalités SVG est arrivé dans les navigateurs, mais principalement dans les domaines où le SVG Working Group (groupe de travail SVG) a renoncé à sa propriété, de sorte que la fonctionnalité passe dans CSS. C'est à la fois un bien et un mal : le CSS est une pierre angulaire du Web, et donc l'ajout de fonctionnalités là, plutôt que dans SVG, rend plus probable leur adoption par les navigateurs ; en revanche, cela affaiblit la position de SVG comme un standard autonome, et oblige les applications qui ne sont pas des navigateurs à se conformer à des normes qui conviennent souvent mal en dehors d'un environnement Web, diminuant la position de SVG comme format de fichier indépendant.

With more features moving to CSS, and the vendors showing little interest in implementing those that remain part of SVG, there's even been talk of not renewing the SVG Working Group's charter beyond a short period to stabilise the work that has been done on the SVG 2 specification over the past couple of years. That would mean no SVG 3, and no new features in the future. Given how many great ideas were dropped from SVG 2 with the promise that they could be revisited for later specs, this would be a tragedy. Sure, Inkscape would likely continue, probably adding proprietary extensions to SVG to support new features as time goes on. But the promise of an open vector format that could be used cross-application, and rendered natively on the web, would have died. Is there anything that we, as users and advocates of open formats, can do to help ensure that SVG has a future? Since it's largely in the hands of the browser vendors, the best we can to is to show them that there is a demand for the format, and for the new additions that are being made to it. We need to create more SVG documents, especially those with features from the SVG 2 specification, and post them online. And we need to encourage others to do the same. But this approach isn't without its problems.

Étant donné que plus de fonctionnalités passent dans CSS et que les fournisseurs montrent peu d'intérêt à implémenter celles qui restent dans SVG, il a même été question de ne pas renouveler la charte du SVG Working Group au-delà d'une période courte pour stabiliser le travail qui s'est fait sur la spécification SVG 2 dans les deux dernières années. Cela signifierait pas de SVG 3, et aucune fonctionnalité nouvelle dans le futur. Étant donné le nombre de bonnes idées qui n'ont pas été intégrées dans SVG 2 avec la promesse qu'elles pourraient être reprises dans des spécifs. ultérieures, ce serait une tragédie. Bien sûr, Inkscape continuerait sans doute, ajoutant probablement à SVG des extensions propriétaires pour supporter des nouvelles fonctionnalités au cours du temps. Mais l'espoir d'un format vectoriel ouvert qui puisse être utilisé sur des applications multiples, et être rendu nativement sur le Web, serait mort.

Y a-t-il quelque chose que nous, utilisateurs et avocats des formats ouverts, pouvons faire pour aider à assurer que SVG a un avenir ? Puisque c'est en grande partie dans les mains des fournisseurs de navigateurs, le mieux que nous puissions faire est de leur montrer qu'il y a une demande pour ce format, et pour les nouveaux ajouts qui lui sont faits. Nous devons créer des documents SVG, spécialement ceux qui utilisent les fonctionnalités de la spécification SVG 2, et les poster en ligne. Et nous devons encourager les autres à faire de même. Mais cette approche n'est pas sans problèmes.

The SVG 2 spec isn't yet finalised. Creating documents using the current version could render them obsolete if there are further changes to the specification before it's finally ratified. So any files you create now might require some (hopefully minor) fixes if they are still to work in a year's time. A bigger problem for most people is how to create them in the first place. Hand-coding SVG is certainly possible, but it's probably not a practical option for most people, which means that the only way to get new features into your files is to wait for them to become available in authoring tools. Thankfully, Inkscape is, to some extent, leading the way for this approach. The recent 0.92 release adds support for rendering several SVG 2 features, although, unfortunately, UI support for creating them in the first place is somewhat more limited. Nevertheless, there are a couple of SVG 2 features that you can start using in your Inkscape drawings today, the first of which I'll cover in this article, and the second next time. The first step towards using these new features is, of course, to install version 0.92.x of Inkscape. Windows users can just download an installer from https://inkscape.org/en/download/windows/ whereas MacOS users are left behind somewhat, with no official .dmg files available at the time of writing (see https://inkscape.org/en/download/mac-os/ for more details and alternative options).

La spécif. SVG 2 n'est pas encore finalisée. La création de documents utilisant la version actuelle pourrait les rendre obsolètes s'il y a des changements ultérieurs de la spécification, avant qu'elle ne soit enfin ratifiée. Aussi, n'importe quel fichier que vous créeriez maintenant pourrait nécessiter des corrections (mineures, j'espère) s'il doit encore fonctionner d'ici un an. Un plus gros problème est que la plupart des gens ne savent pas comment en créer un de toutes les façons. Le codage SVG à la main est sûrement possible, mais ce n'est pas une option praticable par la majorité des gens, ce qui veut dire que la seule façon de placer des nouvelles fonctionnalités dans vos fichiers est d'attendre qu'ils deviennent disponibles dans les outils de création. Heureusement, Inkscape est, jusqu'à un certain point, à la pointe dans cette approche. La récente publication de la 0.92 ajoute du support pour restituer plusieurs fonctionnalités de SVG 2, bien que, malheureusement, le support d'une interface utilisateur pour les créer est quelque peu limité. Néanmoins, il y a deux fonctions de SVG 2 que vous pouvez commencer à utiliser dès aujourd'hui dans vos dessins ; je vais expliquer la première dans cet article et la seconde dans le suivant.

La première étape pour l'utilisation de ces nouvelles fonctionnalités est, bien sûr, d'installer la version 0.92.x d'Inkscape. Les utilisateurs de Windows peuvent télécharger un installeur à partir de https://inkscape.org/en/download/windows/ alors que les utilisateurs de MacOS sont un peu à la traîne sans fichier .dmg officiel disponible au moment où j'écris (regardez sur https://inkscape.org/en/download/mac-os/ pour d'autres détails et des solutions alternatives).

Linux installation instructions vary between distributions, but there's now a distribution-independent Snap package available. Systems that aren't based on Ubuntu may have to install the “snapd” daemon separately (see https://snapcraft.io/docs/core/install for details), but if you're already on Ubuntu 16.04 or later, you should simply be able to run the following command: sudo snap install inkscape Unfortunately the snap doesn't necessarily have all the prerequisites to get Inkscape up and running correctly. One change in 0.92, for example, is that Inkscape no longer bundles a built-in copy of the Potrace library (for tracing bitmaps or using the bucket fill tool); I had to use: sudo apt-get install libpotrace0 to get it working on my system. There have also been theming issues with early snaps (which I also fixed by apt-get installing some additional libraries), although by the time you read this, there should have been a point release which fixes those issues. I strongly recommend launching Inkscape from the command-line at first (just enter “/snap/bin/inkscape”) as error messages in the console may make it clear if there are any unmet dependencies, whereas launching from an icon might leave you with no Inkscape window, and no indication as to what went wrong.

Les instructions d'installation sous Linux varient suivant les distributions, mais un paquet Snap indépendant des distributions est maintenant disponible. Les systèmes qui ne sont pas basés sur Ubuntu peuvent avoir à installer séparément le démon « snapd » (regardez sur https://snapcraft.io/docs/core/install pour les détails), mais si vous utilisez Ubuntu 16.04 ou ultérieur, vous devriez pouvoir simplement lancer cette commande :

sudo snap install inkscape

Malheureusement, les snaps n'ont pas forcément tous les pré-prequis pour installer et rendre Inkscape opérationnel. Par exemple, il y a une modification dans Inkscape 0.92 qui n’intègre plus la bibliothèque Potrace (pour tracer des bitmaps ou utiliser l'outil de remplissage Pot de peinture). J'ai dû utiliser :

sudo apt-get install libpotrace0

pour qu'il marche sur mon système. Il y a aussi des problèmes de thèmes avec les premiers snaps (que j'ai résolus aussi en installant des bibliothèques complémentaires avec apt-get), bien que, au moment où vous lirez ceci, il puisse y avoir eu une publication ponctuelle qui résoudra ces problèmes. Je recommande chaudement de lancer Inkscape par la ligne de commande au départ (saisissez juste « /snap/bin/inkscape » car les messages d'erreur à la console pourraient vous éclairer si certaines dépendances sont insatisfaites, alors que le lancement depuis l'icône pourrait vous laisser sans fenêtre Inkscape et sans indication de ce qui ne va pas.

If you already have Inkscape installed via the normal Apt tools, you will find that the old version is still installed, even after you've added the snap – and that it probably gets run in preference to the new release when you just execute “inkscape” from the command-line, or click the launcher in your menu. You'll need to modify your path to give the /snap/bin directory priority over /user/bin or update your launchers and links to point to the snap version instead. There are still traditionally packaged versions available for several distributions as well, which is especially useful if you have an older system that doesn't support snaps. See https://inkscape.org/en/download/linux/ for details. For example, on Ubuntu 14.04, you might prefer to use the stable PPA that is available, by issuing these commands: sudo add-apt-repository ppa:inkscape.dev/stable sudo apt-get update sudo apt-get install inkscape Whichever approach you take, it's worth visiting Help > About Inkscape to ensure that you are running version 0.92.

Si vous avez déjà installé Inkscape par l'outil apt habituel, vous aurez trouvé que la vieille version est toujours installée, même après que vous avez ajouté le snap, et qu'elle démarre de préférence à la nouvelle publication quand vous exécutez simplement la commande « inkscape » en ligne de commande, ou cliquez sur le lanceur de votre menu. Vous devrez modifier le chemin pour donner la priorité au répertoire /snap/bin sur /user/bin ou mettre à jour vos lanceurs et liens pour qu'ils pointent sur la version snap.

Il y a toujours des versions paquagées traditionnellement disponibles pour plusieurs distributions, ce qui est particulièrement utile si vous avez un ancien système qui ne supporte pas les snaps. Voyez sur https://inkscape.org/en/download/linux/ pour les détails. Par exemple, sur Ubuntu 14.04, vous pourriez préférer l'utilisation du PPA stable qui est disponible en tapant ces commandes :

sudo add-apt-repository ppa:inkscape.dev/stable

sudo apt-get update

sudo apt-get install inkscape

Quelle que soit l'approche que vous choisissez, il vaut mieux visiter Aide > À propos d'Inkscape pour vous assurer que vous faites tourner la version 0.92.

The first SVG 2 feature exposed in the UI is “paint-order”. This is actually a rather uncontroversial feature for the browser vendors, as it has already been implemented in at least Firefox, Chrome, Opera and Safari. It solves a very common problem in SVG, especially when dealing with text: any stroke applied to an object is painted on top of the fill, and extends half in and half out of the object. Consider this simple bit of text, rendered in a cursive font: Suppose we want to add an outline to it, to make it stand out a little bit more against its background. That's simple enough, right? Just give it a thin stroke. Unfortunately that's where the problems start. It certainly stands out more (the fact that the fill appears darker is an optical illusion that helps enhance the effect further), but, due to the construction of the font, we've now got bits of the outline appearing “inside” letters, where the tail of one flows into the body of the next. We can adjust the kerning to separate the problem characters, but that pretty much defeats the point of using a cursive font in the first place. Converting the letters to paths, then creating a boolean union, fixes the visual problem, but now our text isn't actually text any more, which in many cases makes this approach a non-starter. Let's suppose we resign ourselves to having to separate the letters. A little manual kerning gives us this:

La première fonction de SVG 2 exposée dans l'interface utilisateur est l'« ordre de coloriage ». C'est en fait une fonction qui ne prête pas à discussion parmi les fournisseurs de navigateurs, car elle a déjà été implémentée, au moins dans Firefox, Chrome, Opera et Safari. Elle résout un problème très ordinaire dans SVG, souvent dans des textes : tout trait appliqué à un objet est dessiné au-dessus du remplissage et se place moitié dans et moitié hors de l'objet. Regardez ce simple bout de texte, restitué dans une police cursive :

Supposez que nous voulons lui ajouter un contour afin de le faire ressortir un petit peu plus du fond. C'est assez simple, non ? Mettez-lui simplement un trait fin. Malheureusement, c'est ici que commencent les problèmes.

Il ressort certainement plus (le fait que le remplissage paraisse plus sombre est une illusion d'optique qui aide à augmenter encore l'effet), mais, du fait de la construction de la police, nous avons l'impression maintenant que des bouts du contour apparaissent « dans » les lettres, où la terminaison de l'une court dans le corps de la suivante. Nous pouvons ajuster le crénage pour éloigner les caractères à problème, mais cela rend l'utilisation d'une police cursive biens moins intéressante. La conversion des lettres en chemins, puis la création d'une union booléenne, résout le problème visuel, mais, maintenant, notre texte n'est plus du tout un texte, ce qui n'est pas une solution. Supposons que nous nous résignions à séparer les lettres. Une peu de crénage à la main nous donne ceci :

What if we want it to stand out a bit more? Let's double the thickness of the stroke and see what effect it has. Urk! That's not good. All the thin parts of the script have become completely filled by the stroke, ruining the light elegance that we wanted from the font in the first place. The problem, of course, is that increasing the thickness of the stroke not only adds more pixels to the outside of it, but also to the inside, obscuring more of the fill. One common solution to this – and to the previous problem – is to copy the text, putting an unstroked version directly on top of a stroked copy. This works, but now you've got two text objects to keep in sync. With a little effort you can do the trick with clones instead, using an unset fill and stroke, but, if you want anything other than a black fill, you'll be trying to keep three objects (a text object and two clones) under control.

Que se passe-t-il si nous voulons le faire ressortir un peu plus ? Doublons l'épaisseur du trait et regardons l'effet.

Pouah ! Ce n'est pas bien. Toutes les parties fines de l'écriture sont devenues entièrement remplies par le trait, détruisant la fine élégance que nous attendions de cette police. Le problème, bien sûr, est qu'en accroissant l'épaisseur du trait, non seulement nous avons plus de pixels à l'extérieur, mais aussi, à l'intérieur, obscurcissant plus le remplissage. Une solution classique à ce problème - et au précédent - est de copier le texte, plaçant une version sans contour directement sur la version avec contour. Ceci fonctionne, mais, maintenant, nous avons deux objets à maintenir synchronisés. À la place, avec un peu d'effort, nous pouvons utiliser la même astuce avec des clones, en utilisant des remplissage et contour indéfinis ; mais, si nous voulons autre chose qu'un remplissage noir, nous devrons maîtriser trois objets (un objet texte et ses deux clones).

The problem would completely go away if only you could tell Inkscape to render the fill on top of the stroke, instead of the other way round. And that's precisely what the SVG 2 “paint-order” property does! Except it goes a step further, and also includes any markers that are on the path. Considering all the possible orderings for the three things to be rendered, this gives six possible combinations: • Fill, Stroke, Markers • Fill, Markers, Stroke • Stroke, Fill, Markers • Stroke, Markers, Fill • Markers, Fill, Stroke • Markers, Stroke, Fill The first of these is the default, and is the way that SVG 1.x operated. But now there's an extra section in the Stroke Style tab of Inkscape's Fill and Stroke dialog that presents six buttons to let you choose your preference for any selected paths. In each icon, the circle represents a marker, the dark blue rectangle is the fill, and the light blue path represents the stroke, with a dashed white line to indicate its centre. You can produce a similar collection of shapes by drawing a square with a thick border, converting it to a path, then setting a start marker. Clicking each of the buttons whilst your bigger version is selected will immediately reflect the change, and make it much clearer to see what the result of each option is. I recommend creating a shape like this and switching between the different modes to help you to fully understand the effect.

Le problème serait complètement résolu si nous pouvions dire à Inkscape de restituer le remplissage au-dessus du trait, plutôt que l'inverse. Et c'est précisément ce que fait la propriété « ordre de coloriage » de SVG 2 ! Sauf qu'elle est allée un peu plus loin, et inclut aussi tous les marqueurs qui sont sur le chemin. En considérant tous les ordres possibles de restitution de ces trois choses, nous obtenons six combinaisons possibles : • Remplissage, Trait, Marqueurs. • Remplissage, Marqueurs, Trait. • Trait, Remplissage, Marqueurs. • Trait, Marqueurs, Remplissage. • Marqueurs, Remplissage, Trait. • Marqueurs, Trait, Remplissage.

Le premier est la valeur par défaut et c'est ainsi qu'opérait SVG 1.x. Mais, maintenant, il y a une section supplémentaire dans l'onglet Style de contour du dialogue Remplissage et contour d'Inkscape qui présente six boutons pour vous permettre de choisir votre préférence pour tous les chemins sélectionnés.

Sur chaque icône, le cercle représente un marqueur, le rectangle bleu foncé, le remplissage, et le chemin bleu clair, le trait, avec une ligne blanche pointillée pour indiquer son centre. Vous pouvez reproduire un ensemble similaire de formes en dessinant un carré avec un bord épais, puis le convertir en chemin et, ensuite, régler un marqueur de début. En cliquant sur chacun des boutons alors que votre version plus imposante est sélectionnée, la modification est instantanément appliquée et le résultat de chaque choix est beaucoup plus facile à voir. Je vous recommande de créer une forme comme celle-ci et de passer successivement d'un mode à l'autre pour vous permettre de bien comprendre l'effet.

As for our text, because there are no markers involved, any of the three modes that draw the stroke before the fill will give our desired result, with only a single text object and no need for clones, copies, or other workarounds. It even works well with a really thick outline. Even though paint-order is already well supported in browsers, I urge you to create new designs and works of art that use it, and put them online. The more files we share that use SVG 2 features, the more likely it is that the browser vendors might realise there's a demand for them, so going after “low hanging fruit” such as this is an easy way to express your interest without having to worry about posting files that don't render in the browser. Next time I'll move onto Mesh Gradients – perhaps one of the most useful, and most desperately needed, new features in SVG 2, but one which is in very real danger due to browser vendor antipathy.

Pour ce qui est de notre texte, parce qu'aucun marqueur n'est inclus, chacun des trois modes qui dessine le trait avant le remplissage donnera l'effet que nous souhaitons, avec seulement un objet texte, sans avoir recours à des clones, des copies ou toute autre contournement. Et cela fonctionne bien, même avec un contour très épais.

Même si l'ordre de coloriage est déjà bien supporté dans les navigateurs, j'insiste pour que vous créiez vos nouveaux dessins et autres œuvres d'art en l'utilisant et les mettiez en ligne. Plus il y aura de fichiers qui utiliseront les fonctionnalités de SVG 2, plus les fournisseurs de navigateurs seront amenés à se rendre compte qu'une demande pour cela existe. Ainsi, choisir cette solution sans réelle difficulté est une manière facile d'exprimer votre intérêt sans avoir à vous soucier de fichiers qui ne seraient pas correctement restitués dans le navigateur.

La prochaine fois, je passerai aux Dégradés tramés - peut-être l'une des nouvelles fonctionnalités de SVG 2 les plus utiles, et dont le besoin est le plus criant, mais qui est vraiment en réel danger du fait de l'aversion des fournisseurs de navigateurs.