N. Brownlee (University of Auckland)December20162016-12-16
Dans la longue liste de RFC décrivant le
nouveau format des RFC (commencez par le ), ce document décrit l'utilisation de
SVG pour faire (enfin) des graphiques dans
les RFC.
Traditionnellement, en effet, seul le texte était possible dans
les RFC. (On pouvait toutefois faire des
graphiques en art ASCII, dont on imagine
bien que ce n'était ni très pratique à écrire - malgré l'excellent
mode Emacspicture-mode,
ni très facile à lire.) Il y avait de bonnes raisons à cet état de
fait, notamment le manque d'un format d'images ouvert et largement
répandu. Je parle bien sûr d'images
vectorielles car, a priori, dans un RFC, il
y aura beaucoup plus de schémas que de photos.
Le processus de décision a été long et compliqué. En 2013, le
notait déjà la décision de
permettre des images, en indiquant « Graphics may include ASCII art and a more complex form to be
defined, such as SVG line art ». C'est désormais
possible. Au fait, c'est quoi, SVG ? Il
s'agit d'une norme d'un format d'images
vectoriel, gérée par le
W3C, et
fondée sur XML. Voici un exemple d'un simple dessin en
SVG :
]]>
Et voici son rendu :
Les RFC n'utiliseront qu'un
sous-ensemble de SVG, spécifié ici. Il existe d'autres sous-ensembles de
SVG comme SVG Tiny, prévu pour des
équipements contraints, genre
smartphones. Ce SVG Tiny
a servi de base au SVG des RFC, sous-ensemble limité car on
n'attend pas de dessins artistiques et compliqués dans les RFC.
SVG RFC est donc SVG Tiny moins les
éléments permettant le multimédia et l'animation (pas de vidéos dans les RFC),
l'interaction (pas d'interface utilisateur active dans un RFC),
l'utilisation de langages de programmation (pas de
JavaScript actif dans un RFC). Plusieurs
autres restrictions ont été apportées : pas de couleur (, section 3.2), pas
d'IRI, seulement des
URI, et pas de choix arbitraire de
police.
Comment on écrit du SVG ? S'il est évidemment possible de le
faire entièrement à la main avec un éditeur ordinaire, gageons que
peu de gens le tenteront. Notre RFC cite des éditeurs graphiques,
produisant du SVG, comme les logiciels libresInkscape et
Dia. (Et, si on aime programmer en
Python, il y a svgwrite, que
je présente plus en détail à la fin.) Attention, Inkscape et Dia produisent du SVG
généraliste, pas du SVG RFC, qui est plus restreint. (Je ne
connais personnellement pas d'outil pour produire du SVG RFC, ou
pour « réduire » un fichier SVG généraliste en enlevant tout ce
qui n'appartient pas à SVG RFC. Un tel outil était prévu mais je
ne sais pas où il en est. C'était une des fonctions attendues du
futur svgcheck.)
Et l'accessibilité (section 4) ? Il est
crucial que les RFC soient accessibles à tou·te·s, non seulement
que que soit le matériel utilisé, mais également quels que soient
les handicaps dont souffre leur propriétaire. C'est bien joli de
vouloir ajouter des tas de choses dans les RFC mais encore faut-il
ne pas creuser ainsi davantage le fossé entre les
utilisateurs. Ainsi, accepter de la couleur (le limite les futurs RFC au noir et blanc) fait courir
le risque que les daltoniens ne puissent
pas comprendre un RFC. De même, les graphiques, qui ont l'air
comme ça d'être une bonne idée, peuvent aggraver la situation des
malvoyants. Le texte seul peut toujours
être lu à voix haute par un synthétiseur de
parole mais pas le graphique. Comme le note le RFC
avec humour, « lire le source SVG à voix haute ne va pas le
faire ».
Le texte « Tips for
Creating Accessible SVG » donne des bons conseils
pour faire du SVG accessible. Et il y a bien sûr la norme
ARIA, dont il existe une
introduction et de bons
exemples. (Désolé, je n'ai pas suivi ces excellents
principes dans les exemples ci-dessous, mais j'accepte les
patches.)
Si vous voulez voir des exemples concrets, regardez . Ainsi,
l'exemple de schéma d'un en-tête TCP
donnera :
Et le schéma de la communication SIP du
fera
L'annexe A de notre RFC donne un schéma complet (formulé en
Relax
NG) du SVG des RFC. Il est extrait ici dans le fichier
, que vous pouvez utiliser pour tester
la conformité de vos SVG. Par exemple, avec
rnv :
% rnv files/svg-rfc.rnc files/tcp-header.svg
files/tcp-header.svg
En revanche, avec du SVG trop « riche » (ici, utilisant
les couleurs), on aurait :
% rnv files/svg-rfc.rnc /tmp/test1.svg
...
/tmp/test1.svg:2:267: error: attribute ^fill with invalid value "red"
required:
value ^token "none"
value ^token "black"
value ^token "white"
value ^token "#000000"
value ^token "#FFFFFF"
value ^token "#ffffff"
value ^token "inherit"
Une alternative, pour tester la validité des SVG conformes à ce
profil, sera svgcheck quand il
sera développé.
Avec Inkscape, il faut veiller à sauver le
fichier en Plain SVG (autrement, on a des
ennuis avec les éléments spécifiques d'Inkscape,
ex-Sodipodi). Mais il reste malgré cela deux ou trois trucs à
corriger manuellement, avant que le document produit par Inkscape
soit accepté. Pour Dia, il faut utiliser
l'action Export (par défaut, Dia n'enregistre
pas en SVG), mais Dia produit alors un document avec une
DTD. Si on la retire (manuellement, ou bien
avec xmllint --dropdtd), tout se passe bien,
le document SVG est alors conforme au profil demandé pour les
RFC.
Autre solution que j'aime bien pour faire du SVG, dès qu'on a
des éléménts répétitifs et qu'on veut donc automatiser (en
Python), svgwrite. Ce
schéma en art ASCII :
+--------------+ +----------------+
| Alice |------------------------------------| Bob |
| 2001:db8::1 | | 2001:db8::2 |
+--------------+ +----------------+
aurait pu être créé avec svgwrite avec , qui donne
Bien sûr, pour un schéma
aussi simple, le gain n'est pas évident, mais il le devient pour
les schémas comportant beaucoup d'éléments récurrents. Mais notez
que svgwrite ne connait pas le profil « SVG pour RFC » et, par
défaut, peut donc produire des SVG invalides (par exemple avec de
la couleur). Le programmeur doit donc faire attention.