1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
Titre: RFC 7996: SVG Drawings for RFCs: SVG 1.2 RFC
Auteur:
Date: Fri 16 Dec 2016 01:00:00 +0100
Lien: https://www.bortzmeyer.org/7996.html
Dans la longue liste de RFC décrivant le nouveau format des RFC (commencez par
le RFC 7990), 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 Emacs
picture-mode[1], 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 RFC 6949 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 :
<>svg xmlns="http://www.w3.org/2000/svg" version="1.2">
<>rect x="25" y="25" width="200" height="200" fill="white" stroke-width="4" stroke="black" />
<>circle cx="125" cy="125" r="75" fill="black" />
<>polyline points="50,150 50,200 200,200 200,100" stroke="black" stroke-width="4" fill="none" />
<>line x1="50" y1="50" x2="200" y2="200" stroke="white" stroke-width="4" />
<>/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 (RFC 6949, 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
libres Inkscape et Dia. (Et, si on aime programmer en Python, il y a svgwrite[2]
, 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[3].)
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 RFC 6949 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[4] » donne des bons conseils pour
faire du SVG accessible. Et il y a bien sûr la norme ARIA, dont il existe une
introduction[5] et de bons exemples[6]. (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
https://www.cs.auckland.ac.nz/~nevil/SVG_RFC_1.2/[7]. Ainsi, l'exemple de
schéma d'un en-tête TCP donnera : Et le schéma de la communication SIP du RFC
4321 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 svg-rfc.rnc[8], que vous pouvez
utiliser pour tester la conformité de vos SVG. Par exemple, avec rnv[9] :
% 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é[3].
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[2]. Ce schéma
en art ASCII :
+--------------+ +----------------+
| Alice |------------------------------------| Bob |
| 2001:db8::1 | | 2001:db8::2 |
+--------------+ +----------------+
aurait pu être créé avec svgwrite avec network-schema-svgwrite.py[10], 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.
Liens:
[1]: http://www.gnu.org/software/emacs/manual/html_node/emacs/Picture-Mode.html (lien)
[2]: https://pypi.python.org/pypi/svgwrite (lien)
[3]: https://iaoc.ietf.org/documents/svgcheck-SOW-02.pdf (lien)
[4]: http://www.sitepoint.com/tips-accessible-svg (lien)
[5]: http://www.w3.org/TR/2010/WD-wai-aria-primer-20100916 (lien)
[6]: http://blog.paciellogroup.com/2013/12/using-aria-enhance-svg-accessibility (lien)
[7]: https://www.cs.auckland.ac.nz/~nevil/SVG_RFC_1.2/ (lien)
[8]: http://www.bortzmeyer.org/files/svg-rfc.rnc (lien)
[9]: http://www.davidashen.net/rnv.html (lien)
[10]: http://www.bortzmeyer.org/files/network-schema-svgwrite.py (lien)
|
