Over the past few months, you’d be forgiven for thinking that this column has morphed from an Inkscape tutorial to a more general “SVG in HTML” series. In practice, I’ve been introducing a little background knowledge before delving into the (limited) JavaScript features that are already present in Inkscape. But that requires just a little more background information about JavaScript itself, and its use in SVG on the web… JavaScript (JS) is the de facto programming language used in web pages. It’s an implementation of a language called ECMAScript, so you might occasionally see that term mentioned. It’s nothing to do with the Java programming language – it just shares a similar name thanks to someone in marketing at Netscape many years ago deciding that ‘brand awareness’ was more important than ‘avoiding decades of confusion’.
Au cours des quelques derniers mois, vous seriez pardonné si vous avez pensé que cette rubrique s'était transformée d'un tutoriel sur Inkscape en une série plus généraliste sur « le SVG dans le HTML ». En pratique, j'ai présenté quelques connaissances de base avant de plonger dans des fonctionnalités (limitées) du JavaScript qui sont déjà présentes dans Inkscape. Mais ceci réclame un peu plus d'information de fond sur le JavaScript lui-même, et son utilisation dans SVG sur le Web…
JavaScript (JS) est de fait le langage de programmation utilisé dans les pages du Web. C'est une implémentation d'un langage appelé ECMAScript ; aussi, vous pourrez rencontrer occasionnellement une mention de ce terme. Ça n'a rien à voir avec le langage de programmation Java, ils partagent simplement un nom similaire grâce à quelqu'un du marketing de Netscape qui a, il y a pas mal d'années, décidé que la « notoriété commerciale » était plus importante que « d'éviter des années de confusion ».
Within a browser, JavaScript gives you the capability to write code that can modify the page and respond to interactions initiated by the user, or by external actions such as some data being pushed from a server. These triggers are referred to as ‘events’, and will form the core of the JS code we’ll be writing in this series. The basic approach is that we’ll use SVG to draw something to the browser window, then attach events to monitor for clicks, mouse movements, keypresses, and so on, each of which then triggers some JS code which can, in turn, modify the SVG. Because JavaScript can read keypresses from the user, and can talk to a server, it raises security concerns. You could, for example, use SVG to create a beautiful image, but as soon as the mouse moves over it, your JS could redraw the image to look like a legitimate username/password box has opened on the screen. Anything typed into the box could be sent back to your server and used for your own nefarious ends. As a technically aware reader of FCM, you may not be fooled by such an obvious scam, but a huge number of people will happily enter their credentials into such a dialog as an almost Pavlovian response.
Dans un navigateur, JavaScript vous donne la possibilité d'écrire du code qui peut modifier la page et répondre aux interactions initiées par l'utilisateur, ou par des actions externes, telles que des données envoyées depuis un serveur. Ces déclencheurs s'appellent des « events » (événements) et formeront le cœur du code JS que nous écrirons dans cet article. En gros, l'approche va être d'utiliser SVG pour dessiner quelque chose dans la fenêtre du navigateur, puis d'y attacher des événements pour gérer, notamment, des clics, des mouvements de la souris, des appuis au clavier, chacun d'eux déclenchant un peu de code JS qui peut, à son tour, modifier le SVG.
Comme JavaScript peut lire les appuis de l'utilisateur sur des touches, et peut converser avec un serveur, il pose des problèmes de sécurité. Vous pourriez, par exemple, utiliser SVG pour créer une belle image, mais, dès que la souris passe au-dessus, votre JS pourrait redessiner l'image pour qu'elle ressemble à une vraie boîte de dialogue pour identifiant et mot de passe qui s'est ouverte à l'écran. Tout ce qui serait saisi dans la boîte serait alors renvoyé au serveur et utilisé malheureusement à vos dépens. Comme vous êtes un lecteur techniquement averti du FCM, vous ne vous feriez pas avoir par une telle arnaque, mais un très grand nombre des gens entreraient gentiment leurs identifiants dans une telle boîte de dialogue, presque comme par un réflexe pavlovien.
To prevent such attacks, browsers limit the ability of SVG to run JavaScript, depending on how the SVG has been included in the page. I’ve talked about this previously, but it’s worth recapping: SVG in an <img>: This is how images are usually displayed in a web page, and is used in countless bulletin boards and social media sites. Because anyone can upload any image, there’s a huge potential security hole, so JavaScript in SVG is blocked entirely. SVG as a CSS background-image: Although less frequently used as a way for users to upload images, the code paths used in browsers are pretty much the same for CSS images as for <img> elements, so the previous rule still applies: no JavaScript. Inline SVG: This requires the actual code of the page to be edited, so it’s assumed that the work is being done by someone in a trusted position, and therefore the browser allows JavaScript.
Pour empêcher de telles attaques, les navigateurs limitent la possibilité pour le SVG de lancer du JavaScript, selon comment le SVG a été incorporé dans la page. J'en avais parlé précédemment, mais c'est bien de récapituler :
SVG dans un <img> : C'est ainsi que les images sont généralement affichées dans une page Web, et c'est utilisé dans un nombre incalculable de sites de tableaux d'affichage et de médias sociaux. Comme n'importe qui peut téléverser n'importe quelle image, il y a un énorme trou de sécurité potentiel ; aussi, le JavaScript dans du SVG est entièrement bloqué.
SVG comme image d'arrière-plan du CSS : Bien que moins fréquemment utilisé par les utilisateurs pour téléverser des images, les bouts de code utilisés dans les navigateurs sont à peu près les mêmes pour les images du CSS que pour les éléments <img> ; aussi, la règle précédente s'applique : pas de JavaScript.
SVG en ligne : Ceci requiert que le vrai code de la page soit édité ; aussi, il est admis que ce travail doit être fait par une personne de confiance et, donc, le JavaScript est autorisé.
SVG in an <object> This is the W3C standard way to include “foreign” content into a web page – including Flash, Java applets, and other potentially dangerous code. As such, it’s always had a more lax set of security rules than <img>, and no sensible website developer allows user-uploaded content to be displayed in an <object>. Therefore it’s considered to be something that is added only by someone in a trusted position, and JavaScript is allowed. SVG in an <iframe>: Using an <iframe> has a simple syntax, similar to an <img>, but still allows JavaScript like an <object>. I tend to use <object> as that’s the officially recommended approach by the W3C, but there are times when an <iframe> is a better option.
SVG dans un <object> : C'est la façon normative du W3C pour inclure du contenu « étranger » dans une page Web, y compris du Flash, des applets Java, et d'autres codes potentiellement dangereux. Comme tel, il a toujours eu un ensemble de règles de sécurité plus souple que <img> et aucun développeur de site Web sensé n'autorise que du contenu téléversé par un utilisateur soit affiché dans un <object>. Ainsi donc, c'est considéré comme quelque chose qui est ajouté uniquement par une personne de confiance, et JavaScript est autorisé.
SVG dans une <iframe> : Une <iframe> a une syntaxe simple d'utilisation, voisine de celle d'une <img>, mais le JavaScript est autorisé comme pour un <object>. J'ai tendance à utiliser un <object>, car c'est l'approche recommandée par le W3C ; mais il y a des moments où une <iframe> est une meilleure option.
There’s one final way to display an SVG image in a browser which doesn’t involve embedding it into an HTML file in any way, and that’s simply to load the SVG file directly. For an SVG file on your local machine, you can just press CTRL-O and find it in the file selector. For one sent by a web server, the browser’s URL field just has to point directly at the SVG image, and the browser will load it in the same manner as if you pointed directly at a PNG or JPEG file… …except it won’t. Not unless the server has been configured correctly. Which is a whole other story of politics and pain in which countless users and developers suffer from an ideological disagreement at a technical level. Brace yourself, this is going to get petty!
Il y a une dernière façon d'afficher une image SVG dans un navigateur qui ne nécessite en aucune manière de l'incorporer dans un fichier HTML ; c'est de charger directement le fichier SVG. Si le fichier SVG est sur votre machine locale, vous avez juste à appuyer sur Ctrl-O pour le rechercher dans le sélecteur de fichier. Pour un fichier envoyé par un serveur Web, le champ pour l'URL dans le navigateur doit directement pointer sur l'image SVG et le navigateur la chargera de la même manière que si vous pointiez sur une image PNG ou JPEG…
…sauf qu'il ne le fera pas. Sauf si le serveur a été configuré correctement. Ce qui est une toute autre douloureuse histoire de grands principes dans lesquels d'innombrables utilisateurs et développeurs ont souffert d'un désaccord idéologique au niveau technique. Accrochez-vous ; ça va devenir mesquin !
Serving an SVG file isn’t terribly tricky. Your web server has to be configured to send the right MIME type (a header that tells the browser what sort of file it’s receiving), but that’s usually a small configuration change. If you’ve got direct control over the configuration of your server, search online for some appropriate terms (e.g. “Apache SVG MIME”), and you should find suitable instructions. If your server is managed by someone else – such as the typical case of a website hosted by an ISP – first try putting an SVG image onto your site and accessing it, as there’s a good chance the configuration has already been done. If the file appears as text, the browser tries to save rather than display it, or there’s a message suggesting the browser’s treating it as an XML document, you’ll need to raise a support request with your host.
Envoyer un fichier SVG n'est pas terriblement compliqué. Votre serveur Web doit être configuré pour envoyer le bon type MIME (une entête qui dit au navigateur quel est le type de fichier qu'il reçoit), mais c'est, en général, une petite modification de la configuration. Si vous avez le contrôle direct de la configuration du serveur, cherchez en ligne avec les termes appropriés (par ex. « Apache SVG MIME ») et vous devriez trouver des instructions convenables. Si votre serveur est géré par quelqu'un d'autre - ce qui est le cas typique pour un serveur hébergé par un FAI (Fournisseur d'Accès à l'Internet) - essayez d'abord de mettre votre image SVG sur votre propre site et d'y accéder, car il y a de bonnes chances que la configuration ait déjà été faite. Si le fichier apparaît comme du texte, si le navigateur essaie de le sauvegarder plutôt que de l'afficher, ou s'il y a un message suggérant que le navigateur le traite comme un document XML, vous devrez demander de l'aide à votre hébergeur.
Where it gets more complex is with SVGZ files – “compressed SVG” in Inkscape’s terms. These are literally just SVG files that have been compressed using the Gzip algorithm, and you can get the same effect by using the gzip program on your Linux box: gzip -k image.svg mv image.svg.gz image.svgz The first line creates a gzipped version of “image.svg” but doesn’t overwrite the original file (due to the -k switch). Gzip defaults to simply appending “.gz” to the filename, so the second line renames the file to the standard “.svgz” (this could also be done directly with the “–suffix” switch to gzip). The resultant file can be directly loaded into Inkscape for further editing – it’s indistinguishable from a “compressed SVG” file saved from Inkscape itself. On the surface, SVGZ seems like a great format, as it’s much smaller than an equivalent SVG file, but you can still open it in Inkscape, or even convert back and forth from the command-line if you do want to edit the XML content by hand. The problems come when you try to put an SVGZ file online.
Là où ça devient plus compliqué c'est avec les fichiers SVGZ - « SVG compressé » en termes d'Inkscape. Ce ne sont en fait que de fichiers SVG qui ont été compressés avec l'algorithme Gzip ; vous pouvez obtenir le même résultat en utilisant le programme gzip sur votre appareil Linux :
gzip -k image.svg
mv image.svg.gz image.svgz
La première ligne crée une version « g-zippée » de « image.svg » mais n'écrase pas le fichier d'origine (du fait du commutateur -k). Par défaut, Gzip ajoute « .gz » au nom du fichier ; aussi, la seconde ligne renomme le fichier avec l'extension classique « .svgz » (ceci peut être fait directement avec le commutateur « –suffix » dans gzip). Le fichier résultant peut être chargé directement dans Inkscape pour une future modification - il n'y a aucune différence avec le fichier « SVG compressé » sauvegardé par Inkscape lui-même. En surface, SVGZ semble être un bon format, car il est beaucoup plus petit que le fichier SVG équivalent, mais vous pouvez toujours l'ouvrir dans Inkscape, ou même le convertir dans un sens puis dans l'autre avec la ligne de commande si vous voulez modifier le contenu XML à la main. Les problèmes arrivent quand vous essayez de mettre un fichier SVGZ en ligne.
The W3C working group that created SVG thought, quite rightly, that defining a compressed form of the format as part of the spec would be a worthwhile addition, especially back in 2001 when storage space and bandwidth were more expensive. Gzipping of content on-the-fly was already a standard feature of the web, so browsers had decompression code in place, making for an obvious choice of algorithm. Unfortunately, this is where an ideological divide took place: rather than treat SVGZ as a format in its own right, the browser vendors opted to natively support only uncompressed SVG. But saying that is like stating that browsers support only uncompressed HTML or CSS. In practice you can send any supported format with on-the-fly Gzip compression, provided your web server correctly sets the “content-encoding” header. This also means that you can send a pre-compressed SVGZ file if you also provide that header – the browser just thinks you’ve sent an SVG file using on-the-fly compression. Once again, search online for the instructions for your web server, or raise a support request with your ISP if necessary.
Le groupe de travail du W3G qui a créé SVG pensait, à juste titre, que la définition d'une forme compressée du format comme partie intégrante de la spécif. serait un ajout valable, surtout en 2001 quand l'espace de stockage et la bande passante étaient plus coûteux. Le « g-zippage » du contenu à la volée était déjà une fonctionnalité classique du Web, et les navigateurs avaient déjà mis en place le code de décompression, faisant le choix évident de l'algorithme. Malheureusement, c'est là qu'une division idéologique a eu lieu : plutôt que de traiter SVGZ comme un format de plein droit, les fournisseurs de navigateurs n'optèrent nativement que pour le support du SVG non compressé.
Mais dire cela, c'est comme faire état du seul support des HTML ou CSS non compressés dans les navigateurs. En pratique, vous pouvez envoyer n'importe quel format pris en charge avec une compression Gzip à la volée, à condition que votre serveur Web règle correctement l'entête « content-encoding » (codage du contenu). Cela signifie aussi que vous pouvez envoyer un fichier SVGZ pré-compressé si vous fournissez aussi l'entête - le navigateur pense simplement que vous avez envoyé un fichier SVG avec une compression à la volée. Une fois encore, recherchez en ligne les instructions pour votre serveur Web ou demandez de l'aide à votre FAI, si nécessaire.
The summary, therefore, is that browsers don’t really support SVGZ, but with the right server configuration, you can trick them into using those files nevertheless. It also explains why you can’t load an SVGZ file directly into your browser from the local filesystem – if the file doesn’t come from a web server, there’s no “content-encoding” header, and the browser decides to play dumb. This situation could easily be fixed if browsers opted to treat SVGZ as a first class file format, and automatically unzip it even in the absence of the header. But as the situation is unlikely to change, I recommend sticking with SVG files and using on-the-fly compression from your web server, rather than trying to work directly with SVGZ files.
En résumé, les navigateurs ne supportent donc pas vraiment le SVGZ, mais, avec la bonne configuration du serveur, vous pouvez les tromper et utiliser malgré tout ces fichiers. Cela explique aussi pourquoi vous ne pouvez pas charger directement un fichier SVGZ dans votre navigateur à partir de votre système de fichiers local - si le fichier ne vient pas d'un serveur Web, il n'y a aucune entête « content-encoding » et le navigateur décide de rester muet. Cette situation pourrait être facilement résolue si les navigateurs optaient pour traiter le SVGZ comme un format de fichier de première classe et les dézippaient automatiquement même en l'absence d'entête. Mais la situation a peu de chance de changer. Je recommande de s'en tenir au format SVG et d'utiliser la compression à la volée depuis votre serveur Web, plutôt que d'essayer de travailler directement avec des fichiers SVGZ.
Personally, I think the browser vendors are wrong on this one. JPEG images, for example, are essentially just arrays of pixels that are compressed using a “discrete cosine transformation” (DCT) algorithm. Yet browsers don’t insist on a “content-encoding: DCT” header to display a JPEG. The philosophical difference between a file that has been compressed using Gzip by the server, and one that has been natively stored in a gzipped format, is a subtle one. But the result is that users suffer from the complexity and confusion of not being able to directly load an SVGZ file into the browser, even though that format has been explicitly sanctioned by the SVG Working Group.
Personnellement, je pense que les fournisseurs de navigateurs ont tort dans ce cas. Les images JPEG, par exemple, ne sont en gros que des tableaux de points qui sont compressés en utilisant un algorithme de « transformée en cosinus discrète ou TCD » (en anglais : DCT, Discrete Cosine Transform). Pourtant, les navigateurs n'exigent pas un entête « content-encoding: DCT » pour afficher un JPEG. La différence philosophique entre un fichier qui a été compressé avec Gzip par un serveur et un qui a été nativement stocké dans un format g-zippé est subtile. Mais le résultat est que les utilisateurs souffrent de la complexité et de la confusion de ne pouvoir charger directement un fichier SVGZ dans le navigateur, même si ce format a été explicitement approuvé par le groupe de travail du SVG.
To begin our journey into the world of Inkscape and JavaScript, I’ll assume that you are able to load an Inkscape-created SVG file into your web browser, either from a web server or from the local filesystem. Later on, we’ll look at some differences that apply when you use <object>, <iframe>, or inline SVG, but, right now, let’s keep things self contained in a simple SVG file. Remember those JavaScript ‘events’ I spoke of earlier? Let’s use Inkscape to add some JS code that listens for a “click” event – the result of the user clicking on an object in our image. Create a new image, draw a simple object, then right-click on it and bring up the Object Properties dialog. At the bottom of the dialog is a series of fields, all with labels that start with the word “on”. If they’re not visible, you’ll need to click on the “Interactivity” label to expose them. In the “onclick” field, enter the following JavaScript code: alert('Clicked')
Pour commencer notre voyage dans le monde d'Inkscape et de JavaScript, je présume que vous êtes capable de charger un fichier SVG créé avec Inkscape dans votre navigateur Web, soit à partir d'un serveur Web, soit depuis un système de fichiers local. Par la suite, nous regarderons quelques différences qui s'appliquent quand vous utilisez <object>, <iframe>, ou un SVG en ligne, mais, pour l'instant, gardons les choses incorporées dans un simple fichier SVG.
Vous souvenez-vous des « events » du JavaScript dont j'ai parlé avant ? Utilisons Inkscape pour ajouter du code JS qui attend un événement « clic » - le résultat du clic de l'utilisateur sur un objet de notre image. Créons une nouvelle image, dessinons un objet simple, puis faisons un clic droit dessus pour ouvrir le dialogue des Propriétés de l'objet. En bas de ce dialogue se trouve une série de champs, tous avec des étiquettes qui commencent avec les lettres « on ». S'ils ne sont pas visibles, vous devrez cliquer sur l'étiquette « Interactivité » pour les faire apparaître. Dans le champ « onclick » (lors d'un clic), entrez le code JavaScript suivant :
alert('Clicked')
Save the file and load it into your web browser. You should see the object you drew in Inkscape. Click on it to confirm that the browser presents you with a dialog that contains the word “Clicked”. This type of dialog, referred to as ‘an alert’, is the simplest form of output from JavaScript. You can display only a single string, and you can’t change the layout of the dialog or the label on the button. But writing even this most simplistic of code is a useful first step in any JavaScript application: it proves that Inkscape, your browser, and your web server (if you have one) are all working as expected, and it confirms that your code can respond to mouse clicks, which is a basic requirement for almost any interactive site. The single line of code you wrote above does one thing: it calls a function named alert() when the user clicks the left mouse button (or taps) on the object to which you attached your code. The function is given a single parameter – a string containing the word “Clicked” – which it displays on the screen in a dialog. Let’s see how that code in Inkscape manifests itself in the SVG file. Open the SVG file in a text edito and, towards the bottom of the file, you should find something similar to the code shown on the next page, top right.
Sauvegardez le fichier et chargez-le dans votre navigateur Web. Vous devriez voir l'objet que vous avez dessiné dans Inkscape. Cliquez dessus pour confirmer que le navigateur vous présente bien le dialogue qui contient le mot « Clicked ». Ce type de dialogue, qui s'appelle une alerte, est la forme de sortie la plus simple du JavaScript. Vous ne pouvez afficher qu'une simple chaîne, et vous ne pouvez pas changer l'aspect du dialogue ou l'étiquette du bouton. Mais même l'écriture de ce simplissime morceau de code est un premier pas utile dans toute application en JavaScript : il prouve qu'Inkscape, votre navigateur et votre serveur Web (si vous en avez un) fonctionnent tous comme prévu, et cela confirme que votre code peut répondre à des clics de la souris, ce qui est un besoin de base pour à peu près tous les sites interactifs.
La simple ligne de code que vous avez écrite au-dessus fait une chose : elle appelle une fonction nommée alert() quand l'utilisateur clique avec le bouton gauche de la souris (ou fait une rapide frappe du doigt sur l'écran) sur l'objet auquel vous avez attaché votre code. La fonction reçoit un seul paramètre : une chaîne de caractères contenant le mot « Clicked », qui est affichée sur votre écran dans le dialogue. Voyons comment ce code mis dans Inkscape se manifeste dans le fichier SVG. Ouvrez le fichier SVG dans un éditeur de texte et, vers le bas du fichier, vous devriez trouver quelque chose de similaire au code présenté à la page suivante, en haut à droite.
You might have a different element than a <rect>, depending on what you drew – and therefore may have other attributes (the “rx” and “ry” attributes govern the roundedness of a rectangle’s corners, for example). I’ve also significantly abbreviated the “style” attribute. But the thing to note is the “onclick” attribute, which contains the JavaScript we typed into the dialog in Inkscape earlier. It’s worth getting familiar with the way that your JS appears in the file. Whilst the single-line text boxes in Inkscape are okay for typing very short amounts of code, if you need something even slightly more substantial, it’s often easier to edit the SVG directly. Here’s a modified version of my object (with extraneous attributes omitted), to show how you might deal with multiple lines: With those edits in place and saved, reload your page, and click on your object again. This time you should see a series of three alerts.
Vous pourriez avoir un élément autre qu'un <rect>, selon ce que vous avez dessiné, et, en conséquence, avoir d'autres attributs (les attributs « rx » et « ry » gouvernent la rondeur des angles du rectangle, par exemple). J'ai aussi largement réduit l'attribut « style ». Mais ce qu'il faut noter est l’attribut « onclick » qui contient le JavaScript que nous avons saisi un peu plus tôt dans la boîte de dialogue d'Inkscape.
Il vaut mieux être à l'aise avec la façon dont le JavaScript apparaît dans le fichier. Alors que des champs avec une seule ligne de texte conviennent pour saisir de très courtes quantités de code, si vous avez besoin de quelque chose de plus conséquent, il est souvent plus facile de modifier directement le SVG. Voici une version modifiée de mon objet (les attributs non concernés ont été éliminés), pour vous montrer comment gérer des lignes multiples :
Ces modifications étant mises en place et sauvegardées, rechargez la page et cliquez à nouveau sur l'objet. Cette fois-ci, vous devriez voir une série de trois alertes.
Unfortunately, edits made like this don’t reflect well back in the Inkscape UI. Your three lines will be present, but all put onto a single line, and with any white space that you used to align them included in the line. Generally it’s easiest to edit code in either a text editor, or in Inkscape, but not to go back and forth between them. As you’ve guessed from the Inkscape UI, there are other events you can react to. But, in most cases, using the alert() function will prevent you testing correctly. Consider trying the onmousemove option, which is supposed to fire events continuously as your mouse moves over your object: as soon as your mouse moves over the object you’ll get an alert which you’ll need to dismiss before you can continue; then another, and another, each time your mouse moves over the object, with you having to manually dismiss each one in turn. Hardly the constant stream of events you were interested in.
Malheureusement, les modifications faites ainsi ne se voient pas bien dans l'interface utilisateur d'Inkscape. Vos trois lignes seront présentes, mais toutes sur la même ligne et avec tout espace blanc que vous avez utilisé pour les aligner inclus sur cette ligne. Généralement, le plus facile est de modifier le code, soit dans un éditeur de texte, soit dans Inkscape, mais sans passer de l'un à l'autre.
Comme vous l'avez deviné en regardant l'interface d'Inkscape, il y a d'autres événements sur lesquels réagir. Mais, dans la plupart des cas, l'utilisation de la fonction alert() vous empêchera de faire des tests correctement. Faisons un essai de l'option onmousemove, qui est supposée déclencher des événements en permanence quand votre souris passe au-dessus de votre objet : dès que votre souris passera au-dessus de votre objet, vous recevrez une alerte que vous devrez rejeter avant de pouvoir continuer ; ensuite, une autre, puis une autre ; à chaque fois que votre souris passe au-dessus de l'objet, vous devrez rejeter l'alerte manuellement. Pas tout à fait le flux régulier d’événements qui vous intéressait.
Back in the dim and distant past, debugging by throwing up alert messages was the de facto way to develop with JavaScript, but, thankfully, the tools have moved on a lot since then. Modern desktop browsers all have a developer toolbox which you can usually open by pressing F12. There are a variety of tools in here, but the one we’re interested in is the console – there should be a tab for it somewhere near the top of the toolbox. In Inkscape try adding a console.log('Mouse moved') call to the onmousemove section of the object properties: Now, with the file saved and the developer console open, reload your file in the browser. Clicking should throw up an alert, as before, but moving the mouse around over your object should generate a stream of messages in the console. Actually you’re likely to only see one message, plus a count to the right of the console indicating how many times the message has been logged. This is a convenience in modern tools to avoid filling your screen with duplicate messages. If you really want to see them streaming by, you can add a random number to your log entry so that each one becomes unique: console.log('Mouse moved', Math.random())
Il y a longtemps, le débogage par l'envoi de messages d'alertes était de fait la façon de développer avec JavaScript, mais, heureusement, les outils ont beaucoup changé depuis lors. Les navigateurs modernes des ordinateurs de bureau ont tous une boîte à outils de développement que vous pouvez habituellement ouvrir en appuyant sur F12. Dedans, vous trouverez une grande variété d'outils, mais celui qui nous intéresse est la console - il devrait y avoir un onglet pour elle quelque part près du haut de la boîte à outils. Dans Inkscape, essayez d'ajouter un appel console.log('Mouse moved') dans la section onmousemove des propriétés de l'objet :
Maintenant, le fichier étant sauvegardé et la console développeur ouverte, rechargez votre fichier dans le navigateur. Un clic devrait faire apparaître une alerte, comme précédemment, mais des mouvements de la souris au-dessus de l'objet devrait générer un flux de messages dans la console. En fait, vous ne verrez probablement qu'un seul message, plus un chiffre, sur la droite de la console, qui indique combien de fois le message a été enregistré. C'est une facilité des outils modernes d'éviter de remplir votre écran avec plusieurs messages identiques. Si vous voulez vraiment les voir en flux, vous pouvez ajouter un chiffre aléatoire à votre saisie d'enregistrement de sorte que chacun devienne unique :
console.log('Mouse moved', Math.random())
This demonstrates another huge advantage of console.log() over alert() – you can give it multiple parameters, and they don’t all have to be strings. That’s a very basic start to adding some interactivity to an Inkscape file. We’ll be exploring this topic a lot more over the coming months, so please do try the simple exercises above so that you’ve got a good basis to build on as we make our events do more interesting things than just printing some text to the screen.
Ceci démontre l'autre énorme avantage de console.log() sur alert() : vous pouvez lui associer plusieurs paramètres et ils ne sont pas forcément des chaînes de caractères.
Ceci est un début très basique pour l'ajout d'une interactivité à un fichier Inkscape. Nous explorerons ce sujet beaucoup plus dans les prochains mois ; aussi, essayez les exercices simples ci-dessus de sorte que vous disposerez d'une bonne base sur laquelle s'appuyer quand nous créerons des événements pour faire des choses plus intéressantes qu'un simple affichage de texte à l'écran.
A blatant plug! Mark and his colleague Vince have been using Inkscape and MyPaint to create the monthly Elvie cartoon strip, first in Linux Voice, then in Linux Magazine (Linux Pro Magazine in the US), for five years now. To celebrate this anniversary, Mark has written an article in issue #220 of Linux (Pro) Magazine which describes the process they use in some detail. If you’re interested in reading about the practicalities of creating a cartoon using FOSS, this issue should still be current by the time FCM#142 comes out, but it’s also available to buy as a digital edition from http://www.linux-magazine.com/
De la publicité manifeste !
Mark et son collègue Vince utilisent Inkscape et MyPaint pour créer la bande dessinée mensuelle Elvie, d'abord dans Linux Voice, puis dans Linux Magazine (Linux Pro Magazine aux USA), depuis 5 ans maintenant. Pour célébrer cet anniversaire, Mark a écrit un article dans le n° 220 de Linux (Pro) Magazine qui décrit en détail le processus qu'ils utilisent. Si vous êtes intéressé par la lecture des détails pratiques de la création d'une bande dessinée en utilisant les FOSS (Free and Open Source Software - Logiciels libres et Open Source) ce numéro devrait être toujours disponible à la sortie du FCM n° 142 ; mais, il est aussi possible d'acheter l'édition numérique sur http://www.linux-magazine.com/