Initiale releaseHEADmaster

1 files changed, 159 insertions, 0 deletions

diff --git a/RFC_7995_PDF_Format_for_RFCs.txt b/RFC_7995_PDF_Format_for_RFCs.txt
new file mode 100644
index 0000000..8aebd18
--- /dev/null
+++ b/RFC_7995_PDF_Format_for_RFCs.txt
@@ -0,0 +1,159 @@
+Titre: RFC 7995: PDF Format for RFCs
+Auteur: 
+Date: Fri 16 Dec 2016 01:00:00 +0100
+Lien: https://www.bortzmeyer.org/7995.html
+
+Parmi les nombreux formats de publication des RFC prévus suite à l'adoption du 
+nouveau format (RFC 7990), ce RFC décrit l'utilisation de PDF. On pourra donc, 
+en suivant ces règles, avoir une jolie version papier des RFC.
+
+Actuellement, les RFC peuvent bien sûr être imprimés mais c'est un peu 
+tristoune (cf. annexe A). Avec le nouveau cadre de gestion des RFC, le format 
+canonique du RFC sera du XML (RFC 7991), à partir duquel seront produits 
+automatiquement (par des outils qui ne sont pas encore développés) divers 
+formats. HTML sera sans doute le principal pour une publication en ligne (RFC 
+7992), mais il y a des partisans de PDF, surtout pour l'impression sur le bon 
+vieux papier. Ce RFC 7995 décrit donc l'utilisation de PDF comme format de 
+sortie pour les RFC. À noter que ce format, créé et piloté par une entreprise 
+privée n'est pas à proprement parler un « format Internet » et est sans doute 
+moins connu des participants à l'IETF que ne l'est HTML.
+
+La norme PDF est déposée à l'ISO (ISO 32000-1) mais l'archaïque ISO ne 
+distribue toujours pas librement ces documents. Si on veut apprendre PDF, il 
+faut donc le télécharger sur le site d'Adobe[1].
+
+Première question (section 2 de notre RFC), quelle version de PDF choisir ? PDF
+a évolué dans le temps, chaque version ajoutant de nouvelles fonctions. C'est 
+aujourd'hui un format très complexe, difficile à mettre en œuvre complètement. 
+C'est pour cela qu'il existe des profils de PDF, restreignant ce format pour 
+des usages spécifiques. Ainsi, PDF/X est conçu pour l'échange de fichiers avec 
+l'imprimeur. Pour les RFC, documents souvent normatifs, et à longue durée de 
+vie, les exigences principales sont l'accessibilité et la stabilité. C'est ce 
+que fournissent les profils PDF/UA (accessibilité) et PDF/A-3 (archivage à long
+terme).
+
+Pour les RFC, les profils choisis sont la version 1.7 de PDF, suffisamment 
+ancienne pour être gérée par la plupart des logiciels, le profil PDF/A-3 pour 
+limiter le nombre de fonctions à gérer, et PDF/UA pour l'accessibilité.
+
+La section 3 de notre RFC détaille ensuite toutes les exigences particulières 
+des RFC, pour le format de sortie PDF. Je ne les commente pas toutes ici, 
+seulement celles qui me semblent importantes. Par exemple, la délicate question
+des polices. PDF permet d'inclure une police dans le document, ou bien de se 
+référer simplement à une police par son nom. Dans ce dernier cas, si le 
+logiciel qui lit le PDF ne trouve pas exactement cette police, il se rabat sur 
+une police « proche », avec un résultat qui n'est pas forcément satisfaisant. 
+De toute façon, PDF/A, le profil « archivage » impose d'inclure la police 
+utilisée, pour éviter de dépendre de logiciels futurs. À noter que cela peut 
+impliquer de payer : peu de polices sont gratuites pour l'auteur. L'annexe C.4 
+discute des polices acceptables. Il y a les gratuites, mais sans support 
+Unicode complet, comme Source Sans Pro, Source Serif Pro ou Source Code Pro. 
+Bien meilleure du point de vue de la couverture Unicode, mais payante, est 
+Skolar[2]. L'idéal sera peut-être la nouvelle police Noto[3]. Les RFC ayant 
+maintenant le droit d'utiliser des caractères non-ASCII, mais avec des 
+restrictions (cf. RFC 7997), il est possible que des caractères soient refusés 
+par le RFC Editor uniquement parce qu'ils ne sont pas présents dans les polices
+utilisées.
+
+Le choix des caractéristiques des polices (chasse fixe ou variable, empattement
+ou pas) devra suivre les mêmes règles que pour HTML et CSS, règles qui figurent
+dans le RFC 7993. À propos de HTML, notons d'ailleurs que notre RFC sur PDF 
+demande que le PDF ressemble visuellement autant que possible au document HTML.
+Si vous écrivez un logiciel qui produit le PDF pour un RFC et que vous hésitez 
+sur tel ou tel aspect graphique, consultez le RFC 7992 sur la sortie HTML.
+
+Parmi les autres exigences pour la production de PDF, notre RFC demande qu'on 
+évite les césures.
+
+PDF permet de mettre des liens hypertextes. L'intérêt est faible puisque PDF 
+est surtout utilisé pour le papier (si on regarde sur un écran PDF n'a aucun 
+avantage par rapport au format bien plus ouvert qu'est HTML), mais le RFC 
+prévoit quand même cette possibilité. Il y aura donc des liens, à la fois 
+externes (vers des URL, y compris vers d'autres RFC et, dans ce cas, le RFC 
+7322 requiert que cela soit vers la page d'information officielle du RFC Editor
+) et internes (une section du RFC référençant une autre). Les liens internes 
+sont parfois produits automatiquement (par exemple depuis la table des matières
+vers les sections du texte).
+
+Un problème délicat est celui de la façon dont le texte est stocké dans le 
+document PDF. PDF permet en effet plusieurs façons de réaliser ce stockage. 
+Elles donnent le même résultat visuel mais se comportent différemment pour des 
+fonctions comme la recherche de texte. Ainsi, le mot « IETF » peut être stocké 
+comme une image, comme quatre lettres positionnées indépendamment, ou comme un 
+mot unique. Le stockage en image posera évidemment des problèmes aux outils 
+comme pdftotext (mais ce n'est pas forcément grave pour les RFC, on a toujours 
+le source XML) ou aux outils de synthèse vocale, nécessaires aux malvoyants. 
+Pour la recherche de texte, la solution du mot unique est certainement 
+meilleure, même si elle ne permet pas une typographie aussi subtile. Mais il y 
+a aussi le placement des phrases. La phrase « The IETF supports the Internet » 
+peut être stockée comme cinq mots différents stockés indépendamment (y compris 
+dans un ordre différent de celui de la phrase) et positionnés ensuite, ou bien 
+comme un objet unique.
+
+Notre RFC recommande d'au moins garder les mots dans l'ordre du texte (PDF/UA 
+l'impose).
+
+Pour les images, si le source XML contenait à la fois de l'art ASCII et du SVG,
+notre RFC impose bien sûr qu'on utilise le SVG pour produire le PDF. Le texte 
+alternatif aux images, indispensable pour l'accessibilité[4], doit être mis 
+dans le PDF (dans la propriété /Alt).
+
+Les métadonnées (noms des auteurs, date, etc) sont très utiles pour 
+l'indexation et la recherche et doivent donc être mises dans le PDF. PDF a 
+plusieurs façons d'embarquer des métadonnées, et la recommandation est 
+d'utiliser XMP.
+
+Parmi les zillions de fonctions de PDF, il peut agir en container d'autres 
+fichiers (oui, comme tar ou AVI). Tous les logiciels PDF ne savent pas extraire
+ces fichiers embarqués dans le PDF mais c'est une fonction utile, au cas où. Le
+RFC recommande donc que des fichiers utiles soient ainsi embarqués : le source 
+XML du RFC, les codes sources (dans les éléments <>sourcecode> du RFC), les 
+images (dont les sources SVG)...
+
+Dernier point, les éventuelles signatures. Pour l'instant, il n'y a pas de 
+mécanisme standard pour signer les RFC et en garantir l'authenticité mais, 
+lorsque ce sera le cas, PDF permettra d'inclure une signature dans le fichier 
+produit. (Cette fonction existe dans PDF depuis longtemps.)
+
+Le RFC contient aussi trois annexes intéressantes. L'annexe A est un historique
+de la relation compliquée entre les RFC et PDF. Depuis longtemps, une version 
+PostScript du RFC était acceptée par le RFC Editor et publiée, même si très peu
+d'auteurs en ont profité. Cela concernait surtout les RFC ayant des images ou 
+des formules mathématiques comme les RFC 1119 ou RFC 1142. Le PDF produit par 
+le RFC Editor pour tous les RFC (ou par https://tools.ietf.org/[5]) n'était, 
+lui, qu'une simple « impression » du RFC en texte brut.
+
+L'annexe B rappelle ce que doit faire un bon logiciel de production de contenu 
+imprimé, avec découpage en pages. C'est plus dur que cela n'en a l'air, car il 
+faut gérer les veuves et les orphelines, ne pas couper juste après le titre 
+d'une section, ne pas couper les dessins en art ASCII, placer les tableaux 
+intelligemment, etc.
+
+Enfin, l'annexe C décrit une partie des outils disponibles pour le producteur 
+de documents PDF. Si les logiciels de visualisation sont nombreux, il faut 
+noter que tous n'ont pas la totalité des fonctions qu'utilise le format de 
+sortie des RFC (par exemple les liens hypertexte). Du côté des imprimantes (le 
+papier étant le but final de la plupart des documents PDF), certaines savent 
+même gérer le PDF directement (dans les autres cas, ce sera au logiciel de 
+visualisation de produire le format attendu par l'imprimante, souvent 
+PostScript).
+
+Et pour produire le PDF à partir du XML des RFC ? Une solution possible, 
+puisqu'il existe une feuille de style XSLT (disponible en ligne[6]) est de 
+produire du FO qui sera ensuite transformé en PDF, par exemple avec FOP (je 
+n'ai personnellement eu que des expériences décevantes avec FO). Mais il existe
+plein de bibliothèques qui produisent du PDF, et qui pourraient être utilisées.
+
+Comme notre RFC impose l'utilisation de profils de PDF comme PDF/A, un outil 
+important est le logiciel de vérification qui s'assure que le résultat est bien
+conforme aux exigences de ce profil. Pour l'instant, il semble qu'il n'existe 
+pas grand'chose dans ce domaine. Il faudra donc compter sur l'outil de 
+production de PDF pour qu'il fasse un travail correct.
+
+Liens:
+[1]: http://www.adobe.com/devnet/pdf/pdf_reference.html (lien)
+[2]: https://www.rosettatype.com/Skolar (lien)
+[3]: https://www.google.com/get/noto/ (lien)
+[4]: http://www.w3.org/TR/WCAG20-TECHS/PDF1.html (lien)
+[5]: https://tools.ietf.org/ (lien)
+[6]: http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#output.pdf.fop (lien)