diff options
Diffstat (limited to '')
-rw-r--r-- | RFC_7996_SVG_Drawings_for_RFCs_SVG_12_RFC.txt | 139 |
1 files changed, 139 insertions, 0 deletions
diff --git a/RFC_7996_SVG_Drawings_for_RFCs_SVG_12_RFC.txt b/RFC_7996_SVG_Drawings_for_RFCs_SVG_12_RFC.txt new file mode 100644 index 0000000..dc314c8 --- /dev/null +++ b/RFC_7996_SVG_Drawings_for_RFCs_SVG_12_RFC.txt @@ -0,0 +1,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) |