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 de ce mois - et 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 est aussi en charge de créer les spécifications du HTML et de CSS. HTML est 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. Ça 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, lui donnant 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 académiquement pures que pouvaient être le objectifs du XHTML, ils sont tombés dans le monde réel. HTML a prospéré en partie parce qu'il était trop laxiste. Les navigateurs on t fait de leur mieux pour interpréter la majorité de la syntaxe mal ficelée, ce qui a grandement abaissé la barrière d'entrée pour que les non-programmeurs créent leurs propres pages Web. Des applications comme Dreamweaver ou HoTMetal l'ont encore plus réduite, car elles permettaient aux utilisateurs de créer des pages Web aussi facilement qu'un document Word. HTML a continué à proliféré sur la toile et çà aurait été un suicide commercial pour tout navigateur que de n'accepter que le XHTML. Du fait de sa pureté et de sa supériorité technique, XHTML a été inévitablement désavantagé face au standard plus inconsistant et le travail du W3C est devenu largement hors de propos. Il était clair que l'approche d'avoir un organisme normatif pour écrire les spécifications, et, seulement ensuite, de les implémenter dans les navigateurs, n'a pas été ce qui a fonctionné en réalité.

Il s'en est suivi une période de stagnation pour le Web. Aucun navigateur ne voulait introduire une syntaxe aussi radicalement nouvelle dans le HTML ou le CSS de peur de ré-activer les mauvais jours anciens des extensions propriétaires. Mais, éventuellement, les entreprises des navigateurs commencèrent à discuter entre elles sur les manières de relancer le Web. Le résultat a été la formation d'un autre organisme normatif, WHATWG, dont le mandat était de d'améliorer largement les vieilles spécifs. HTML, en documentant ce que les navigateurs avaient déjà fait, de sorte à rendre plus facile, pour tous les fournisseurs, la mise à une même niveau de conformité de leurs programmes. Ils ajoutèrent aussi quelques fonctionnalités nouvelles au HTML, sous l'étiquette « HTML5 », bien que nous en sommes à plusieurs années maintenant et que beaucoup de leurs idées les plus utiles n'ont pas été encore 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 revenu dans leur giron. Mais, structurellement, les choses ont changé : fini le temps où le W3C écrivaient 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 les 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 se préparent à 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 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 accepte. Les outils de création (comme Inkscape) aimeraient les implémenter, mais, sans support des navigateurs, la spécif. a peu de chance d'être finalisée et supportée - de sorte que tout travail serait 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 retiennent les outils de création de les adopter ; l'absence d'adoption dans les outils de création freine les utilisateurs de créer et de diffuser 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.

Pour être franc, il y a quelque support limité de nouvelles fonctionnalités SVG 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 est une pierre angulaire du Web, et donc l'ajout de fonctionnalités là, plutôt que dans SVG, permet qu'elles soient adoptées par par les navigateurs ; mais, à l'inverse, ceci réduit la position de SVG comme un standard autonome, et oblige les applications qui ne sont pas des navigateurs à se conformer à des normes qui ne conviennent pas bien 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.

Avec plus de fonctionnalités passant dans CSS et les fournisseurs montrant 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 avait été fait sur la spécification SVG 2 dans les deux dernières années. Cela signifie pas de SVG 3, et aucune fonctionnalité nouvelle dans le futur. Étant donné les nombre de bonnes idées qui sont restées à côté de SVG 2 dans l'espoir qu'elles pourraient être reprises dans des spécifs. ultérieures, ceci serait une tragédie. Bien sûr, Inkscape continuerait pareillement, 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 futur ? Bien que ce soit 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 ajouts qui pourraient lui être fait. 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 à 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'ils doit encore fonctionner d'ici un an. Un plus gros problème pour la plupart des gens est comment le créer la première fois. 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, en pointe dans cette approche. La récente publication 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 initialement est quelque peu limitée. Néanmoins, il y a deux fonctions de SVG 2 qu 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 d'Inkscape. Les utilisateurs de Windows peuvent télécharger un installeur à partir de https://inkscape.org/en/download/windows/ alors que la utilisateurs de MacOS sont un peu à la traîne avec aucun fichier .dmg officiel disponible au moment où j'écris (voyez 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 il y a maintenant disponible un paquet Snap indépendant des distributions. 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 juste lancer cette commande :

sudo snap install inkscape

Malheureusement, les snaps n'ont pas forcément tous les pré-prequis pour pour installer et rendre Inkscape opérationnel. Par exemple, il y a une modification dans Inkscape 0.92 qui ne fait plus le lien avec une copie intégrée de 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 pourrait y avoir eu une publication ponctuelle qui résoudrait ces problèmes. Je recommande chaudement de lancer Inkscape par la ligne de commande la première fois (sisissez juste « /snap/bin/inkscape » car les messages d'erreur à la console pourrait é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 ayez 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 pointer à la place sur la version snap.

Il y a toujours aussi 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.0.4, vous devriez 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

Quelque soit l'approche que vous prenez, 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:

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.

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.

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.