Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Thorium Reader, un logiciel open-source permettant de visualiser et lire des E-Books

17 novembre 2024 à 13:20

Thorium Reader est un logiciel gratuit et open-source (licence BSD 3) développé par EDR Lab permettant de visualiser les livres électroniques au format EPUB 3 sur Windows, Mac et GNU/Linux avec les DRM d'Adobe et les DRM françaises LCP et de lire les livres audio au format MP3.

Les DRM LCP sont utilisées notamment par les bibliothèques et médiathèques françaises et suisses, dans le cadre du Prêt Numérique en Bibliothèque (PNB). Elles sont considérées plus avantageuses pour les éditeurs, car elles évitent de payer les tarifs américains d'Adobe DRM. Les DRM Readium LCP ont été conçues par Readium Foundation, les spécifications sont publiques et existent en tant que ISO/IEC 23078-2:2024.

Thorium Reader permet de naviguer dans les catalogues OPDS. Côté accessibilité « les personnes incapables de lire les textes imprimés bénéficient désormais d'une application de lecture EPUB 3 qui prend en charge les lecteurs d'écran tels que Jaws et NVDA sur Windows, Voice Over sur Mac » (ainsi que Narrator qui fait partie de Windows 11).

Le logiciel est traduit dans 25 langues. Techniquement il repose sur typescript, electron, reactjs, redux, saga et i18next.

Le site Web d'EDRLab nous apprend que c'est une organisation à but non lucratif.

Son budget provient essentiellement de nos membres. EDRLab a démarré en France, mais compte désormais 60 membres en Europe, Amérique du Nord, Amérique du Sud et Asie. Le financement du projet vient des membres fondateurs (Editis, Hachette Livre, Madrigall, Médias-Participations, Cercle de la Libraire, Syndicat national de l'Édition), de subventions publiques françaises (CNL (Centre National du Livre), Ministère de la Culture) et de subventions supplémentaires des membres de l'EDRLab intéressés par l'ajout de fonctionnalités spécifiques (Fênix Editorial, Canadian Electronic Library, MLOL / Horizons Limited, Lyrasis).

Commentaires : voir le flux Atom ouvrir dans le navigateur

epub, le convertisseur EPUB3 à la volée de LinuxFr.org

4 novembre 2024 à 03:57

Le site LinuxFr.org utilise divers logiciels libres pour son fonctionnement et ses services : une large majorité provient de projets tiers (Debian, MariaDB, Redis - version d’avant le changement de licence, nginx, Postfix, conteneurs LXC et Docker, Ruby On Rails, Sympa, etc.) et d’autres composants sont développés pour nos propres besoins. Cette dernière catégorie comprend le code principal du site web en Ruby On Rails, et principalement 5 services autour : le cache d’images img, la tribune board, le convertisseur EPUB 3 epub, le partageur sur les réseaux sociaux share et le convertisseur LaTeX vers SVG svg. Cette dépêche va s’intéresser à epub, un code sous AGPLv3.

Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le convertisseur EPUB3 à la volée de LinuxFr.org, et elle vient accompagner la précédente sur img, le cache d’images sur LinuxFr.org.

    Sommaire

    Des EPUB de vos contenus et commentaires

    LinuxFr.org vous permet de lire les contenus et commentaires du site, au format EPUB3, par exemple dans votre liseuse préférée. Il y a une exception à cela, les liens, parce que certes ça ferait des EPUB tout mignons, mais surtout petits voire un poil inutiles. Le lien EPUB est présent automatiquement sur chaque contenu (hormis les liens donc).

    Le principe est simple : on donne un lien vers un contenu HTML à epub, il le demande à la partie Ruby on Rails du site, ainsi que les images associées, convertit le tout au format EPUB3 et le renvoie à la personne qui l’a demandé. Techniquement epub n'est pas exposé frontalement mais se trouve derrière un nginx.

    Côté code Ruby on Rails

    C’est assez basique : on ajoute juste sur chaque contenu un lien pour télécharger au format EPUB. Ainsi, y compris sur cette dépêche, vous allez trouver un lien à la fin pour récupérer le tout au format EPUB (et un autre pour récupérer le source en Markdown mais c’est un autre sujet).

    app/views/news/_news.atom.builder:    epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
    app/views/polls/_poll.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
    app/views/posts/_post.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
    app/views/nodes/_actions.html.haml:    = link_to "EPUB", "#{path_for_content node.content}.epub", title: "Télécharger ce contenu au format EPUB", class: "action download"
    app/views/diaries/_diary.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))
    app/views/wiki_pages/_wiki_page.atom.builder:  epub = content_tag(:div, link_to("Télécharger ce contenu au format EPUB", "#{url}.epub"))

    Côté epub

    Le service est plutôt simple, par rapport à img, car il n’a pas de dépendance sur redis par exemple, et qu’il a, au final, peu de paramétrage (un couple adresse+port d’écoute, un fichier de trace et un hôte pour aller chercher les contenus).

    Il est possible de faire un GET /status et on obtient une réponse HTTP 200 avec un contenu OK. C’est utile pour tester que le service est lancé (depuis l’intérieur de la plateforme).

    Sinon on lui demande une dépêche, un journal, une entrée de forum, un sondage, une entrée de suivi ou une page wiki en prenant le chemin sur LinuxFr.org et ajoutant un petit .epub à la fin, et il va renvoyer un fichier EPUB. Ou bien il va répondre un contenu non trouvé HTTP 404 s’il y a un souci. Et vu son fonctionnement, si on a un souci de HTML non valide ou si img a un problème avec une image, alors derrière epub pourrait avoir le même souci.

    epub est un binaire dynamique en Go. Il impose le https pour l’hôte (du coup on aura tous les liens en HTTPS en interne normalement). Il ne peut pas vraiment être compilé statiquement (on a besoin de libxml2, libonig2 et de la même version de la libc au déploiement). Il ne gère pas les images in-line.

    Dans les logs on va trouver des infos comme :

    2024/11/03 16:34:02 Status code of http:/example.invalid/exemple.png is: 404
    (…)
    2024/11/03 16:38:23 Fetch https://linuxfr.org/news/capitole-du-libre-2024-au-programme-du-16-et-17-novembre
    2024/11/03 16:38:24 Fetch https://linuxfr.org/users/liberf0rce/journaux/libreast-2006-is-out-of-order
    

    Historique

    epub a été créé par Bruno Michel en 2013 et Bruno est le seul à travailler dessus (48 commits) jusqu’en 2018. Comme img, on peut considérer que epub a fait le job pendant ce temps-là, sans besoin de retouche.

    Mon premier commit de 2021 concerne la gestion d’un cas de collision de nommages des images.

    En 2022, Bruno quitte l’équipe du site, et par ailleurs il y a des montées de versions et des migrations à faire sur les serveurs de LinuxFr.org, et epub fait partie des services à reprendre en main. Ce qui veut dire le comprendre, le documenter et au besoin l’améliorer.

    Bref je décide de me plonger dans epub (2022-2024), dans la foulée de img, car a priori ce n’est pas un composant compliqué du site (il vit dans son coin, il offre une interface, c’est du Go, donc on a un binaire seulement à gérer - divulgâchage en fait non pas seulement).

    Le choix est le même que pour img (cf la dépêche précédente) : ajouter un Dockerfile permettant de recompiler epub dans un conteneur, en contrôlant la version de Go utilisée, en effectuant une détection d’éventuelles vulnérabilités au passage avec govulncheck. Cela me permet de valider que l’on sait produire le binaire d’une part, et que l’on offre à tout le monde la possibilité de contribuer facilement sur ce composant. Et de découvrir qu’une version statique n’est pas facilement envisageable.

    Puis je vais tester le composant pour vérifier qu’il fonctionne comme je le pense et qu’il fait ce qu’on attend de lui. Je vais ajouter une suite des tests qui couvrent les différentes fonctionnalités et les vérifient en IPv4 et en IPv6, en HTTP 1.1 et en HTTP 2.0. Les tests utilisent Hurl et docker-compose, et encore une fois l’idée de donner la possibilité de contribuer facilement. Ils comprennent des tests de types de contenus non pris en charge, le test de la limite à 5 MiB, différents types de contenus, le test de vie, des appels erronés (mauvais chemin, mauvaise méthode, etc). Et surtout de vérifier avec epubcheck que le fichier epub produit est correct. Le choix des cas de tests est basé sur le trafic réellement constaté sur le serveur de production, sur les différents cas dans le code et un peu sur l’expérience du testeur.

    Les différents travaux effectués vont permettre de détecter et corriger quelques soucis :

    Et à la fin, j’écris une dépêche pour parler de tout cela.

    Évolutions récentes

    Dockerfile

    Le fichier Dockerfile du projet permet :

    • de partir d’une image officielle Go d’une version donnée, basée sur une distribution Debian (en raison des dépendances)
    • de l’utiliser pendant la construction en prenant la liste des dépendances de compilation, en les téléchargeant, en prenant l’unique fichier source epub.go et en le compilant dynamiquement avec l’option pour retirer les chemins de compilation
    • de rechercher les éventuelles vulnérabilités avec govulncheck
    • de tester avec golangci/golangci-lint le code (fait à la construction de l’image, car on dispose de toutes les dépendances à ce moment-là)
    • de repartir d’une base Debian en y mettant les autorités de certification, les dépendances de fonctionnement et le binaire issus de la partie construction, de déclarer le port d’écoute et de lancer le binaire avec des variables disposant de valeurs par défaut.

    La suite de tests

    Pour l’utiliser, c’est assez simple, il faut aller dans le répertoire tests et lancer un docker-compose up --build, qui va produire le conteneur contenant epub, et démarrer le nginx-cert qui fournit les certificats et le nginx préconfiguré pour les tests. Si tout va bien, on attend, et au bout d’un moment il s’affiche :

    linuxfr.org-epub-test_1  | All tests look good!
    tests_linuxfr.org-epub-test_1 exited with code 0
    

    Rentrons un peu dans les détails.

    D’abord un fichier docker-compose.yaml qui décrit le réseau IPv4/IPv6 utilisé pour les tests, l’image nginx-cert qui sera utilisée pour créer une autorité de certification et un certificat serveur de test, l’image nginx qui sera utilisée avec sa configuration et ses fichiers à servir pour les tests, l’image epub et son paramétrage (dont l’accès au nginx) ainsi que le répertoire de l’autorité de certification de tests et enfin l’image de la suite de tests qui est construit avec son Dockerfile et son répertoire de dépôt des fichiers EPUB.

    Le Dockerfile de tests est basé sur une image Hurl (un outil pour faire des tests HTTP). On ajoute les fichiers de tests en .hurl, le script shell qui pilote le tout, on prévoit d’avoir les paquets dont on aura besoin : bash (pas par défaut dans les Alpine), curl, openjdk17 (pour epubcheck), openssl, unzip (transitoirement), bind-tools et shellcheck. On installe epubcheck. Et on lance les tests par défaut.

    La configuration nginx de test écoute en HTTP sur le port 80 en IPV4 et IPv6 et permet de définir des chemins avec des réponses en HTTP 301, 302, 308, 400, 401, 403, etc. jusqu’à 530 et même 666 pour les codes invalides, ainsi qu’une redirection infinie.

    Dans les données de tests servies par nginx, on trouve des contenus du mauvais type, des contenus dans divers formats, une image très grande et des images qui ne seront pas accessibles.

    Sont aussi présents deux fichiers de tests avec une extension en .hurl :

    • le test de vie et les chemins hors des contenus autorisés
    • les tests sur les contenus

    Vient enfin le script shell qui pilote le tout :

    • on définit les variables pour les cibles IPv4/IPv6 que l’on veut utiliser dans les autres conteneurs Docker
    • on purge le stockage des EPUB sur disque
    • on lance les premiers tests (en IPv4 et IPv6, en HTTP 1.1 et en HTTP 2.0)
    • sur chaque EPUB produit, on lance epubcheck et on regarde si la validation donne le résultat attendu (succès ou échec)
    • si on est arrivé jusque-là on écrit que tout va bien et on déclenche un sourire de satisfaction.

    Les problématiques restantes

    Il y a quelques entrées encore ouvertes dans le suivi :

    • les images trop grandes (en octet), non récupérables, de format inconnu, etc. : la suite de tests actuelle « couvre » le cas des images de plus de 5 MiB ou non récupérables, avec des tests qui échouent, comme prévu, vu que c’est img qui est censé faire le job de les éviter. Cependant il pourrait être sympa de remplacer toute image non disponible/invalide par une image de remplacement « Image indisponible » du bon Content-Type et du bon nom (vu qu’elle est déclarée dans le MANIFEST).
    • les images trop grandes (en pixel) : globalement on revient à la question des images que laisse passer img
    • les epub non fonctionnels en rédaction et modération : pour des questions de droits, la génération EPUB ne marche pas dans les espaces de rédaction et de modération, à voir si on trouve un contournement ou si on évite de proposer le lien.

    Il y a la question habituelle de la montée de versions des dépendances (pour nous actuellement contraintes celles du code Ruby on Rails). Et des questions à se poser sur l’avenir de nginx ?. Les dépendances pendant le fonctionnement amènent aussi leur lot de contraintes.

    Conclusion ?

    Encore une fois, sans surprise et me répétant, il reste des problématiques et du code à faire pour les gérer (c’est rare un composant sans demandes d’évolution ou de correction). Yapuka (mais probablement plus tard, il faut aussi partager le temps avec les autres composants, ou avoir plus de contributions).

    epub rend la fonction que l’on attend de lui, même si on pourrait faire un peu mieux. Plonger dans ce composant s’est avéré assez intéressant et formateur (et nécessaire) : techniquement cela a été l’occasion de faire du Go, du docker et du docker-compose, du nginx, du hurl, de l’HTTP et de gérer des problématiques statique/dynamique et des dépendances. Il s’agissait encore de comprendre ce que faisait un code écrit par une autre personne, de se poser des questions pour choisir les tests et le contenu de la documentation, de se demander pour quelles raisons tel ou tel choix a été fait, de rendre ce composant plus « contribuable », et de compléter le tout de façon détaillée avec une dépêche.

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    Une histoire de formats : il n’y a pas que la taille qui compte

    Dans cette nouvelle excursion dans le temps et dans l’espace du Transimpressux, nous allons rendre une rapide visite à Théotiste Lefevbvre (1798 - 1887) prote d’imprimerie et à quelques-uns de ses confrères ainsi que dans les magasins de quelques bibliothèques. Nous passerons aussi, un grand moment du côté de la Silicon Valley et de Redmond dans l’État de Washington, bien obligé puisqu’on parlera beaucoup de formats numériques, sans oublier d’aller dire bonjour à Donald Knuth, Tim Berners-Lee et John Gruber. On terminera notre exploration quelque part dans les archives numériques de la Bibliothèque nationale de France (BnF).

    La climatisation du Transimpressux a été entièrement révisée et le bar rechargé en boissons fraîches et glaces en tous genres. On vous souhaite un bon voyage.

    Le transimpressux

    Sommaire

    Préambule

    Cette dépêche ne se veut pas exhaustive sur les formats en tous genres ni très technique sur les formats informatiques. Pour les formats d’image, qui ne sont pas traités ici, je vous renvoie à l’excellente dépêche de Tanguy Ortolo qui a fait le tour de la question et au journal de Glandos sur l’intégration du JPEG XL dans les navigateurs.

    Les formats matériels, entre coût et rangement

    Encore aujourd’hui, le format matériel d’un document, spécialement, s’il s’agit d’un livre, est important pas uniquement pour des questions de coût. Mais aussi à cause d’eux. C’est parce que le papier coûtait cher qu’Alde Manuce a créé l’italique au début du 16e siècle. L’italique prenant moins de place que les autres styles de caractères, il devenait possible d’imprimer des livres en petit format qui pouvaient ainsi être achetés par une clientèle impécunieuse.

    Une pile de livres
    Des différences de taille et de tailles. Image retravaillée avec le filtre « Pencil Portrait » de Q’mic-Qt (et un peu Inkscape).

    Les rouleaux, volumen ou rotulus

    La taille de ces rouleaux varie beaucoup. Ils peuvent atteindre plusieurs mètres de long (ou de large, selon le sens de lecture). Témoin cette remarque d’Auguste Molinier, chartiste et bibliothécaire, en 1892 :

    On a étudié récemment la longueur des volumina antiques. En Égypte, elle paraît avoir été illimitée ; un rouleau trouvé à Thèbes a 43 m. 50, ce qui est excessif ; il est vrai que le moyen âge a eu des rouleaux de parchemin, plus solides, mais encore plus lourds et infiniment plus longs. Pour les œuvres littéraires grecques et latines, un érudit moderne, M. Birt, a évalué à 12 mètres la longueur extrême des volumina.1

    Ces longueurs démesurées ne sont pas propres aux Égyptiens. Les Archives nationales de Paris possèdent un parchemin d’une longueur d’une vingtaine de mètres. Daté de 1307, ce rouleau consigne les aveux, obtenus sous la torture, de cent-trente-huit Templiers. Il va sans dire que leur longueur et leur ancienneté rend les rouleaux très difficiles à manipuler, une difficulté que la numérisation élimine.

    Des formats des livres

    Les noms des formats des livres en imprimerie traditionnelle sont liés au nombre de pages que l’on imprimait sur une feuille. Le mot « format » lui-même pourrait venir des châssis, ou « formes » dans lesquels on plaçait les pages à imprimer. Ce procédé s’appelait l’imposition.

    Les formats les plus usuels, du plus grand au plus petit :

    • in-folio : soit quatre pages par feuille, la taille la plus grande de livre,
    • in-quarto, huit pages,
    • in-octavo, seize pages,
    • in-douze, vingt-quatre pages,
    • in-dix-huit, trente-six pages.

    La répartition des pages sur la feuille était à la fois importante et délicate puisqu’une fois imprimée, la feuille était pliée. Il fallait donc veiller non seulement à la bonne répartition des pages sur la feuille, mais aussi à leur sens. Dans son Guide pratique du compositeur d’imprimerie, Théotiste Lefebvre consacre plus d’un quart de son livre (119 pages sur 440) à cette délicate question. Dans son petit guide sur la Typographie, Charles-Félicien Huart y consacre aussi plusieurs pages.

    Un exemple de répartition des pages2 pour un volume in-douze, « côté de première » indique le recto, « côté de seconde », le verso. La feuille est pliée en trois dans le sens de la hauteur et deux dans la largeur.

    répartition
    Recto : deux séries de pages tête en bas, pages 12, 13, 16 et 9 (1re série) et 8, 17, 20 et 5 (2e série) et, en dessous pages 1, 24, 21 et 4. Verso : deux séries de pages tête en bas, pages 10, 15, 14 et 11 (1re série) et 6, 19,18 et 7 (2e série) et 3, 22, 23 et 2 en dessous.

    Cette différence de tailles peut amener les bibliothèques dont le fond n’est pas directement accessible au public à opter pour un classement matériel des livres basés sur le format. On aura ainsi des côtes du genre « in12-numéro d’inventaire ». C’est un système très efficace et qui évite d’avoir un petit livre (littéralement) perdu au milieu de livres nettement plus grands.

    Les formats actuels, livre et papier

    L’indication de format à partir du nombre de pages imprimées sur une feuille ne donne pas d’information précise sur la taille effective des livres. Il faut signaler que les dimensions changent en fonction de celles de la feuille d’origine. Les appellations actuelles, côté édition, du style Livre de poche (environ 10,5 cm x 17,5 cm), livre broché ou encore grand format, utilisées en lieu et place d’in-folio, in-octavo, etc. réservés plutôt au livre ancien ne sont pas plus précises.

    En, revanche, la taille des feuilles de papier les plus utilisées a fait l’objet d’une norme, la norme ISO 216. Elle concerne les formats A, dont le fameux A4 qui est celui des feuilles standard des imprimantes de bureau et le format B. Le principe : plus le numéro est élevé, plus la feuille est petite. La numérotation commence à 0 qui fait un mètre carré (84,1 cm x 118,9 cm) pour le format A. La taille de la feuille du numéro supérieur devant être égale à la moitié de celle du numéro inférieur qui la précède. En d’autres termes : le format A3 égal deux fois le format A4 qui, lui-même, est deux fois plus grand que le format A5. Il en va de même avec le format B. Cela explique au passage pourquoi le format A4 mesure 21 x 29,7 cm et pas 21 x 30 cm.

    Les formats de texte

    Jusque dans les années 1990, il y avait un nombre très important d’outils et de formats de textes. Writer de LibreOffice, d’après mes comptes, peut ouvrir jusqu’à quarante-quatre formats de fichier différents, hors modèles et hors web, mais n’enregistre que dans des formats qui sont ceux encore utilisés à l’heure actuelle. Ce qui réduit la liste à treize formats incluant les modèles et l’HTML.

    Sur cette frise chronologique, on a, en haut, des formats de texte avec leur date de naissance plus ou moins approximative et, en dessous, des langages de balisage avec leur date de naissance également.

    Formats de texte et langages de balisage
    Les formats de texte : 1977 Texte brut, 1987-2007 RTF, 1990-2007 DOC, 2005 ODT, 2007 DOCX. Ils ont été choisis parce qu’ils sont les plus connus, voire, les plus utilisés. Dans cette liste deux formats ne sont plus maintenus, les formats RTF et DOC. Mais il existe encore des amas de fichiers dans ces deux formats.

    Le texte brut, .txt

    Le texte brut, nait à une date imprécise. Probablement vers la fin des années 1950 ou au début des années 1960. Le premier RFC3 qui définit un standard de protocole pour des messages en texte brut (Standard for the Format of Arpa Network Text Messages) date de 1977, il porte le numéro 733 et a été rédigé par l’agence américaine pour les projets de recherche avancée de défense (DARPA pour Defense Advanced Research Projects Agency).

    Au début, le format n’acceptait que l’Ascii, à savoir les vingt-six lettres de l’alphabet, les chiffres, les ponctuations de base et les caractères de commande Ascii. Ce qui en fait un format simple, mais très pauvre. L’Ascii est codé sur 7 bits, ce qui ne permet d’avoir que cent-vingt-huit caractères, en fait quatre-vingt-dix imprimables et trente-huit pour les codes de commande4. Il accepte, depuis, l’Unicode. Depuis quand ? Difficile à préciser, mais la première mention d’Unicode qui figure sur le site rfc-editor remonte à juillet 1994 (en), RFC 1641, à titre expérimental. On peut supposer, en tout cas, que le consortium Unicode qui réunit la fine fleur de l’informatique a dû très tôt faire en sorte que son standard puisse être accepté dans le format texte brut.

    Ce format se révèle assez vite insuffisant de part sa simplicité même, confinant à la pauvreté : pas d’enrichissement typographique, pas de notion de style ni de hiérarchie des paragraphes, pas de possibilité d’avoir des images. Il est, de fait, plutôt inférieur à ce que l’on peut avoir sur du papier. Il reste néanmoins très utilisé et par toutes les applications qui traitent du texte : éditeurs de texte, bureautique, etc. Il a pour lui l’avantage d’être simple, léger et interopérable. C’est le format, par exemple, avec lequel la BnF Gallica délivre les documents « bruts de numérisation » (il faut copier-coller le texte ailleurs pour le garder et le retravailler), et c’est, bien évidemment, celui des RFC.

    Il y a des personnes qui recommandent de conserver le texte en texte brut, compte tenu des limitations du format, ce n’est pas franchement conseillé pour des documents un peu complexes étant donné qu’il y aura énormément de pertes d’information.

    Le RTF

    En 1987, Microsoft lance le Rich Text Format (RTF) qui permettait d’avoir du texte « enrichi » avec des attributs : gras, italique, souligné et de dépasser le cadre du texte brut. C’est un format qui a été pendant un certain temps, un standard d’échange de fait pour ce type de fichiers. Il était au moins lu par beaucoup de logiciels sur nombre de systèmes d’exploitation. C’était un format pratique d’échange, notamment à une époque où le PDF n’était pas encore un format ouvert et ne pouvait être généré que via le (cher) logiciel d’Adobe. Et aussi parce que c’était l’époque de la « grande démocratisation » de l’informatique, et, qu’à vrai dire, les utilisateurices finaux ne savaient pas trop comment, surtout sous quelle forme et ce qui se passait quand on échangeait des fichiers.

    Aussi pratique que soit le format RTF, outre son absence de légèreté, il était néanmoins très limité : pas de texte structuré autrement que sur un plan purement visuel, par exemple. Microsoft arrêtera de le maintenir en 2008 (il aura tenu vingt ans tout de même !). C’est donc un format mort.

    Le .doc, un format propriétaire incontournable

    Quand Microsoft lance sa suite bureautique dans les années 1990 (la date sur la chronologie n’est pas tout à fait exacte), il adopte pour le traitement de texte, Word, l’extension .doc qui avait été aussi celle de WordPerfect. Word avait pour lui de montrer le rendu du texte immédiatement : le fameux WYSIWYG pour « What you see is what you get » (ce que vous voyez est ce que vous obtenez).

    La suite finit par devenir quasiment incontournable et le format DOC de Word devenir un « standard de fait ». Microsoft abandonnera le DOC en 2007 pour le DOCX basé sur l’Office Open XML. On produira encore longtemps après des fichiers en .doc en vertu du « tout le monde n’a pas la version de MsOffice 2007 ». On trouve encore sur internet des modèles de fichiers à ce format à télécharger.

    Il était reproché au format son poids, lourd, des problèmes de confidentialité (on pouvait, par exemple, retrouver du texte effacé avant l’enregistrement ou le modèle de l’imprimante5) et sa faiblesse devant les virus. Et, bien entendu, c’était un format propriétaire et pas interopérable. Un autre défaut majeur du format était qu’il était modifié à chaque nouvelle version de Word ce qui impliquait de devoir acheter la nouvelle version du logiciel pour pouvoir travailler sur les nouveaux fichiers en .doc.

    Microsoft délivrera les sources du format en 2006, mais les spécifications semblent ne plus figurer sur le site de la firme. Le code source de la version d’origine de Word, quant à lui, a été rendu public et versé au musée américain de l’histoire de l’ordinateur (en).

    Le .doc peut encore être ouvert et travaillé d’un grand nombre de logiciels. Abiword par exemple ouvre les .doc mais pas les .docx. En revanche, il est de moins en moins possible de générer des fichiers à ce format, et c’est une bonne chose. On ne saurait que trop vous suggérer de transformer tous les fichiers en .doc qui traîneraient encore dans vos ordinateurs en ODT (ou de faire le ménage). Il en va de même pour le format de modèle .dot.

    L’ODT : un format ouvert

    En 2005 apparaît un format bien intéressant : le format ODT, qui est une des composantes du plus général OpenDocument Format (ODF) avec le O d’Open, le D de Document et le T de Texte, l’extension OTT étant pour les modèles avec le premier T pour Template (modèle en anglais). L’ODF est géré par le consortium OASIS, pour Organization for the Advancement of Structured Information Standards (Organisation pour l’avancement des normes d’informations structurées).

    OASIS est une structure à but non-lucratif autorisée par l’ISO (International Standard Organization, l’organisation dont l’objectif social est l’élaboration et la publication de normes mondiales de produits et services), à publier des standards dont les spécifications sont publiquement disponibles sans passer par les fourches caudines de l’ISO. Le consortium a été créé en 1993, il s’appelait à l’époque SGML Open. Il était constitué de fournisseurs et d’utilisateurs d’outils informatique, son but était le développement de lignes directrices pour l’interopérabilité de logiciels utilisant le langage de balisage SGML. Il change de nom en 1998 pour devenir OASIS qui reflète mieux les travaux du consortium. Parmi les cent-seize membres (l’adhésion est payante) : à peu près toutes les grandes entreprises de l’informatique américaine et quelques chinoises ou japonaises (Alibaba, Hitachi, Huawei, Fujitsu…) mais aussi des organismes tels que le Parlement européen, l’Office des publications européennes, le Ministère français de l’Intérieur, le FBI, des universités (Brno, Milan, Luxembourg, Oslo, Westminster, MIT, etc.), la Biblioteca del Congreso Nacional du Chili, TheDocumentFoundation, etc. Il existe en outre une fondation européenne à but non lucratif OASIS Open Europe (en) affiliée au consortium et dont l’objectif est de soutenir le rôle de l’Europe dans le développement de l’open source et des normes ouvertes.

    La version 1.0 du format OpenDocument (ODF) pour les applications bureautiques a été approuvée le 1er mai 2005 à l’unanimité des soixante-dix-huit membres ayant voté. La version 1.0 des directives pour l’accessibilité du format ODF, quant à elle a été approuvée à l’unanimité des onze membres ayant voté le 1ᵉʳ mai 2008. La dernière version du format ODF est la 1.3 (en), approuvée le 27 avril 2021. LibreOffice l’a intégré à partir des versions 7, pratiquement à la sortie de la norme, c’est le format d’enregistrement par défaut. La norme ODF 1.3 a mis notamment l’accent sur la signature et le chiffrage des documents.

    Le format ODF est basé sur le XML. C’est un fichier « compressé » qui en contient plusieurs6 :

    • le fichier meta.xml contient des informations au sujet du document (l’auteur, la date de la dernière sauvegarde),
    • le fichier styles.xml contient les styles utilisés dans le document,
    • le fichier content.xml contient le contenu principal du document (texte, tableaux, éléments graphiques…),
    • le fichier settings.xml, en général spécifique à une application, contient certains paramètres tels que l’imprimante sélectionnée…,
    • les fichiers META-INF/manifest.xml contiennent des informations supplémentaires sur les autres fichiers (comme le type MIME ou le chiffrement).

    Plus des dossiers : Pictures, Thumbnails, etc.

    Ce format est le format natif notamment de LibreOffice, OpenOffice7, Calligra, Collabora Online, GoogleDocs, Zoho, il est aussi ouvert, travaillé et enregistré par des logiciels tels que MsOffice depuis 2007 (2016 pour la version pour MacOS), Office365, OnlyOffice ou AbiWord (listes non limitatives).

    L’une de ses très grandes forces est, qu’à l’instar du format HTML, toute la mise en forme repose sur des styles. Ce qui rend très évolutifs et adaptables les documents au format ODT (pour peu qu’ils le soient avec un logiciel qui le gère bien).

    En France, le format ODF est le seul format bureautique recommandé par le référentiel général d’interopérabilité. Le format ODT étant mentionné comme format à privilégier par nombre d’administrations de par le monde.

    Le format DOCX et son OOXML

    L’année 2007 est celle qui « révolutionne » la suite bureautique de Microsoft. En effet, la firme abandonne les vieux formats pour en adopter des nouveaux basés sur le XML d’où le X de l’extension. Mais pas n’importe quel XML, le XML maison appelé Office Open XML (OOXML pour faire court). Il est fort probable que, ce faisant, l’idée était de court-circuiter le standard ODF. Microsoft a d’ailleurs livré une guerre féroce pour que son OOXML soit accepté par l’ISO en s’y reprenant à deux fois. La norme, adoptée le 17 aout 2008, porte le numéro ISO/IEC DIS 29500. Il est possible (probable ?) également que, Word étant ce qu’il est, se baser sur le XML de l’ODT aurait vraisemblablement nécessité un grand travail de refonte du logiciel. Il existe deux « variantes » de DOCX, le premier, celui de la version 2007 et celui de 2010. En effet, la norme ISO/IEC DIS 29500 n’est pas compatible avec Office 2007.

    Sur le plan technique, il est reproché à l’OOXML sa complexité qui en rend difficile la mise en œuvre. À tel point qu’il se dit que Microsoft lui-même ne l’implémente pas correctement. La dernière version d’OOXML est actuellement la référence ISO/IEC 29500-1:2016 (en) de novembre 2016 (elle fait 5024 pages).

    Sur le plan juridique, le caractère libre de la norme est flou, il en ressort une certaine instabilité sur ce plan. Avec les spécifications, Microsoft a distribué :

    un document promettant de ne pas poursuivre les auteurs de l’utilisation d’Office Open XML dans un autre logiciel que ceux de Microsoft. Cette promesse de non-poursuite elle-même laisse certains flous, notamment :
    • s’appliquant à la norme ECMA en l’état, s’applique-t-elle à une éventuelle version finale de l’ISO ?
    • s’applique-t-elle à tous les brevets logiciels nécessaires à la mise en œuvre de la norme ?
    • s’applique-t-elle également aux extensions du format OOXML ?
    La licence d’utilisation de OpenXML est incompatible avec les programmes sous la licence GPL.8

    À l’instar des fichiers ODF, le DOCX est un fichier compressé qui en contient plusieurs. On en trouvera l’anatomie (en) par exemple sur le site Office Open XML (en).9

    Il est actuellement ouvert, voire travaillé et enregistré, de la plupart des suites bureautiques.

    Des langages de balisages

    Parler des formats de texte sans évoquer les langages de balisage serait assez inepte puisque les formats modernes sont basés dessus. Pour rappel, un langage de balisage est un langage servant à définir et à structurer les informations dans un document.

    Il en existe de nombreux, mais on n’évoquera que ceux qui semblent les plus connus ou les plus utilisés.

    TeX le grand ancien

    TeX fait figure de grand ancien, puisque la première version du langage de balisage date de 1978. Cela dit, on devrait peut-être plutôt parler « d’écosystème » car c’est à la fois un format, le langage de balisage utilisé par LaTeX et un logiciel libre de composition. TeX a été créé par Donald E. Knuth, professeur émérite à l’Université de Stanford et considéré comme l’un des pionniers de l’algorithmique. L’objectif de Donald E. Knuth en créant TeX était d’avoir des documents scientifiques et techniques de bonne qualité typographique, ce qu’il n’était pas possible d’obtenir avec les logiciels d’édition de l’époque. Le principe du langage TeX est la séparation du contenu de et la forme, ce qui était innovant.

    TeX est complété par LaTeX qui est « un ensemble de macros permettant de faire beaucoup de choses »10, et, bien sûr, par le langage de composition de polices vectorielles Metafont. LaTeX a été développé par Leslie Lamport. La première version est sortie en 1983.

    Ce n’est pas un traitement de texte, l’idée étant que l’auteur ou l’autrice :

    puisse mettre son énergie à rédiger le contenu sans être distrait par l’apparence de son document. En écrivant en langage LaTeX, l’utilisateur doit donc définir sémantiquement le contenu de son document plutôt que visuellement. DMS, Université de Montréal.

    On peut générer des fichiers TeX soit directement avec un éditeur de texte, soit avec des logiciels comme Lyx ou encore Overleaf qui est un éditeur LaTeX en ligne et collaboratif. Mais, pour en voir le rendu, il faudra soit faire un PDF, si on utilise un éditeur de texte, soit passer par le visualiseur, quand il existe, dans un logiciel tel que Lyx.

    À ma connaissance la plupart des suites bureautiques ne l’acceptent pas, pas plus que Calibre d’ailleurs.

    La dernière version de TeX, 3,143.141592653 date de janvier 2021. Le format est géré par le groupe des utilisateurs de TeX ou TUG (en). LaTeX quant à lui est géré par le projet LaTeX (en). La dernière version date de juin 2024.

    Le SGML et ses petits

    Le SGML, S pour Standard, G pour Generalized, M pour Markup et L pour Langage (langage de balisage généralisé normalisé) possède le numéro de norme ISO 8879:1986. 1986 étant l’année d’obtention du numéro ISO, la première version du SGML étant sortie en 1978. Produit de l’industrie de l’édition, il a adopté, comme TeX, le principe de la séparation complète du fond et de la forme. C’est, en fait, une norme permettant de définir des langages de balisage génériques pour des documents. SGML sera, dès 1984, le format standard des publications officielles des Communautés européennes.

    Ce qui caractérise un document SGML : il doit posséder une « définition du type de document » (DTD ou doctype en anglais). Cette DTD sert à indiquer la structure du document. Et, évidemment le système de balises que l’on va retrouver chez les membres de la famille.

    HTML, sans lequel, possiblement, LinuxFr.org ne serait pas

    Le langage HTML, pour HyperText Markup Language, est un langage de balisage pour l’hypertexte, cette fonctionnalité qui permet de naviguer sur internet. Il a été créé, ou plutôt lancé au début des années 1990 par Tim Berners-Lee qui en a profité pour concevoir au passage la forme des adresses Web que nous connaissons (les URL) et le protocole de communication HTTP.

    Le format HTML est géré par le World Wide Web Consortium (W3C) fondé en 1994 par Tim Berners-Lee. L’objectif du W3C : émettre des normes et des recommandations pour le web.

    La première version de HTML était très limitée : cela n’allait pas plus loin que la structure du texte avec les balises de titres et de listes, et les liens hypertextes.

    En 1999, sort la version 4 (en) qui deviendra une norme ISO en 2000. La norme HTML 4 supporte pleinement le langage de mise en forme CSS (Cascading Style Sheet ou feuilles de style en cascade). Le HTML 4 existe en trois variantes, si on peut dire :

    • le HTML strict qui exclut les éléments de « présentation » puisque qu’il revient au CSS de faire le travail de mise en forme,
    • le HTML transitionnel accepte quelques balises de présentation obsolètes héritées du HTML 3,
    • frameset qui normalise les jeux de cadre, les «frames ».

    La dernière version de HTML est le HTML 5 publié en 2012. Il ne remplace pas le HTML 4.1 : les deux standards coexistent. HTML 5 apporte en plus des fonctionnalités d’animations complexes, multimédia avec de l’audio et de la vidéo, etc. jusque-là assurées notamment par le logiciel privateur Flash. HTML 5 s’est aussi éloigné du SGML.

    XML le futur du HTML

    C’est, en tout cas, ainsi que s’intitulait en 1998 un article (en) de Todd Freter (en) directeur de programme chez Sun Microsystem. Défini comme un sous-ensemble de SGML, « le XML a été conçu pour être facile à mettre en œuvre et interopérable avec SGML et HTML »11. De fait les syntaxes HTML et XML sont les mêmes. L’une des différences fondamentales entre les deux était, au départ, qu’il était possible de définir ses propres balises avec XML, mais pas avec HTML. Un comportement qui a été modifié en 2014 pour HTML avec les Web Components (en).

    XML (eXtensible Markup Language) a été développé par un groupe de travail piloté par le W3C à partir de 1996, avec, comme président, Jon Bosak (en) de Sun Microsystems. Les objectifs, à sa sortie en 1998, étaient les suivants selon la Recommandation du W3C du 10 février 1998 :

    1. XML devrait pouvoir être utilisé sans difficulté sur Internet ;
    2. XML devrait soutenir une grande variété d’applications ;
    3. XML devra être compatible avec SGML ;
    4. Il devrait être facile d’écrire des programmes traitant les documents XML ;
    5. Le nombre d’options dans XML doit être réduit au minimum, idéalement à aucune ;
    6. Les documents XML devraient être lisibles par l’homme et raisonnablement clairs ;
    7. La conception de XML devrait être préparée rapidement ;
    8. La conception de XML sera formelle et concise ;
    9. Il devrait être facile de créer des documents XML ;
    10. La concision dans le balisage de XML est de peu d’importance.

    Qu’en est-il aujourd’hui de ces principes ?

    En fonction de la syntaxe XML du document, s’il est transmis avec le type MIME text/html, il est vu par les navigateurs comme un fichier HTML. En revanche, s’il est transmis avec un type XML MIME, il sera traité comme un document XML. Dans le deuxième cas de figure, des erreurs de syntaxe même mineures empêcheront un document étiqueté XML d’être correctement restitué alors qu’elles seraient ignorées dans la syntaxe HTML. L’objectif 1, n’est donc pas atteint et XML ne remplace définitivement pas HTML. En revanche, XML est effectivement très utilisé : outre les formats ODF et OOXML, c’est le langage sur lequel est basé le format SVG (Scalable Vector Graphics, ou, en français graphique vectoriel adaptable) et c’est le format de référence pour l’échange de données. Mais, pour ce qui est de la lisibilité du format par des yeux humains, elle n’est pas toujours au rendez-vous.

    XML est maintenu par le W3C. La dernière version (en) porte le numéro 1.1, elle est sortie le 29 septembre 2006.

    Langages de balisage léger

    Les langages de balisage léger sont conçus pour être facile à utiliser avec un éditeur de texte. La syntaxe en est simple.

    Le MarkDown, peut-être le plus connu d’entre eux, a été créé en 2004 par le programmeur américain John Gruber; aidé d’Aaron Swartz. Il n’a pas subi d’évolution importante depuis. En revanche, il en existe des variantes. John Gruber le définit comme :

    un outil de conversion de texte en HTML destiné à la rédaction Web. Markdown vous permet d’écrire en utilisant un format de texte brut facile à lire et à écrire, puis de le convertir en XHTML (ou HTML) structurellement valide. Daring Fireball (en).

    Pour en savoir plus sur la syntaxe MarkDown, on peut, très profitablement, se référer au wiki de LinuxFr.org.

    Il en existe d’autres comme txt2tags créé en 2001 ou encore AsciiDoc (en) dont la première version date de 2002. Txt2tags (en) est un logiciel générateur de documents écrit en Python et qui utilise un langage de balisage léger comme source. Quant à AsciiDoc, il se veut un langage particulièrement adapté à la rédaction de documentations techniques. Il existe aussi le langage de balisage du CMS (gestion de contenu web) SPIP, né en 2001.

    L’archivage et la conservation des textes

    Il est ici, évidemment question des formats d’archivage des textes, avec ou sans images, tableaux, formules de mathématiques, etc. Avant d’aborder cette question : une définition s’impose. Il ne s’agit pas des formats dits d’archives de type .zip, .rar, .tar etc. Archiver les textes c’est, dans ce contexte, pouvoir les conserver et y accéder sans avoir besoin de l’application qui a servi à les générer. Et ce soit en conservant la mise en page d’origine, comme pour le PDF, soit en laissant à l’outil de lecture la main pour la mise en page. Chaque format a ses spécificités. Mais de toute façon :

    un bon format de préservation, c’est un bon format tout court. Outils open source nombreux, métadonnées internes bien foutues, démarche collective de normalisation… Bertrand Caron, archiviste numérique à la BnF, janvier 2024.

    EPUB

    L’EPUB, pour Electronic PUBlication, est un format de document numérique qui n’est pas destiné à l’impression. L’une de ses spécificités est, notamment, de laisser à l’utilisatrice ou l’utilisateur le choix du rendu du fichier. Il existe, toutefois, un mode « fixed-layout » qui fige la mise en forme de l’EPUB. Ce mode a été conçu pour les publications qui nécessitent que la mise en page soit respectée, comme certaines publications scolaires. Mais cela réclame une mise en page adaptée aux tailles des écrans des appareils de lecture.

    EPUB a succédé au format OeB (Open eBook). Au départ, géré par l’International Digital Publishing Forum (IDPF) qui sera intégré au W3C en 2017. La première version sort en 2007, suivie, en 2010 par l’EPUB2 et, en 2011, par l’EPUB3. Il a été très vite adopté. Aujourd’hui les deux versions coexistent, l’EPUB2 prédominant encore sur l’EPUB3. Le format est basé sur XML et sur HTML. Un fichier EPUB est un fichier zip qui contient plusieurs fichiers et répertoires dont un dossier META-INF qui contient un fichier container.xml, ce dossier n’apparait pas quand on génère un fichier à partir de Sigil d’ailleurs. Les fichiers de texte sont au format XHTML.

    Qu’apporte l’EPUB3 par rapport à l’EPUB2 ? Les évolutions concernent principalement l’accessibilité et l’intégration de contenus audio ou vidéo. Ainsi les formules de mathématiques qui, en EPUB2 sont converties en images, donc illisibles sans yeux, sont gardées en tant que telles avec EPUB3. Les liseuses ne supportent pas forcément toutes les fonctions, notamment multimédias.

    Il est possible d’y ajouter différents types de marquage ou de verrous : les DRM Adobe, chères et complexes, les DRM LCP, très pratiques pour le prêt des livres en bibliothèque ou encore des filigranes qui n’imposent aucune limitation aux EPUB. L’apposition d’une DRM a un EPUB est, en principe, une décision éditoriale. Il semble néanmoins que certaines librairies éprouvent le besoin d’en rajouter. Il convient donc d’être vigilant quand on achète un EPUB si on veut éviter d’avoir un livre avec une DRM. Le livre numérique représente 10,1 % du chiffre d’affaires de l’édition française en 2023, ce qui inclut les EPUB et les PDF.

    La version la plus récente du format EPUB et l’EPUB3.3 sortie en mai 2023. Elle est devenue une Recommandation W3C (en).

    PDF

    L’objectif du format PDF a contrario de celui de l’EPUB est le respect de la mise en page du fichier qui a servi à le générer. De ce fait, il n’est pas très lisible sur une liseuse ou sur un téléphone.

    La naissance du PDF remonte à 1991 et elle est due à John Warnock cofondateur d’Adobe. La première version de ce format est sortie en 1992. À l’époque c’était assez fou de pouvoir accéder à un fichier avec sa mise en page d’origine sans qu’il soit nécessaire d’avoir l’application qui avait servi à le générer. Il deviendra un standard ouvert géré par l’ISO en 2008, numéro ISO 32000.

    En fait il n’existe pas un, mais plusieurs formats PDF dont :

    • PDF/A pour l’archivage,
    • PDF/E pour les documents techniques,
    • PDF/X pour l’impression,
    • PDF/UA pour l’accessibilité universelle,
    • ou encore des formulaires FDF.

    La version PDF/A-3 permet d’incorporer le fichier d’origine au PDF : dans l’export PDF de LibreOffice, cela s’appelle un PDF hybride. Cela donne un fichier qui pèse deux fois plus lourd, grosso modo, minus le poids des polices embarquées, que le PDF « simple ». Et, si on ouvre le PDF à partir de l’application qui a servi à le créer, ou si on clique sur « Cliquer pour les afficher » (ou équivalent) dans un lecteur de PDF qui le permet, ici Okular, on ouvre le fichier d’origine. Mais, évidemment, quand on le modifie ça ne modifie pas le PDF. Il faut soit générer un nouveau PDF soit l’écraser.

    À savoir, il n’y a que quatorze polices standard PDF, en fait seulement cinq fontes différentes avec leurs variantes, gras, italiques : Courrier, Helvetica, Times Roman, Symbol et Zapf Dingbats. Il est donc très important, quand on génère un PDF d’incorporer les polices au fichier à condition que cela soit permis par la licence des polices. Pour ne pas alourdir le fichier, il est suggéré de n’incorporer que les polices utilisées dans le document. Avec LibreOffice, vous pouvez configurer cela soit en générant le PDF, soit, de préférence, la première fois que vous enregistrez le fichier, c’est dans l’onglet « Police » des propriétés dudit fichier. Si vous utilisez un modèle, la case peut avoir été cochée dans le modèle et il ne sera pas nécessaire de le faire.

    Kurinto une histoire de chasses

    La chasse, en typographie, est l’encombrement d’un caractère : largeur plus approche (espace autour). Pour un même corps de caractère (sa hauteur), elle peut varier selon les polices, ce qui, évidemment, peut changer, voire, chambouler, complètement un document créé avec une police et pour lequel on a changé la typographie. La collection de polices Kurinto (en) a été dessinée à la fois pour couvrir un large éventail de langues et de systèmes d’écriture et dans l’optique de pouvoir remplapcer les polices Microsoft avec des glyphes qui ont la même chasse.

    Si vous cherchez des polices au dessin élégant pour remplacer des fontes comme le couple Arial/Times New Roman, avoir aussi des typographies à chasse fixe ou légèrement fantaisie, l’ensemble de polices Kurinto est un bon choix qui offre en prime une bonne cohérence entre les diverses polices. Elles sont sous licence SIL.

    Déclinaison des noms des polices Kurinto permettant de voir leurs chasses respectives

    Les textes et documents qui ont servi à alimenter cette dépêche

    Les références sont données à peu près dans leur ordre d’apparition dans le texte. Ils sont tous accessibles en ligne et, de préférence, en français. Volontairement, il y a un minimum de références à Wikipédia. Ce n’est pas tout à fait exhaustif, mais ça vous fera déjà pas mal de lecture. Par exemple, je n’ai pas cité le blog de Stéphane Bortzmeyer qui m’a bien servi à défricher le terrain.

    Les formats matériels

    • Sur les rouleaux notamment leur rangement. Le site Rotulus est consacré aux rouleaux médiévaux.
    • Guide pratique du compositeur d’imprimerie, Théotiste Lefèvre, un guide considéré longtemps comme une, si pas LA, référence en matière de typographie et d’imprimerie. Paru en 1855, il fera l’objet de multiples éditions, les dernières en 2000. Aujourd’hui encore, ses pages sur la typographie peuvent servir de références. Théotiste Lefèvre était le fils d’un apprenti compositeur. Il commencera comme ouvrier en imprimerie pour devenir une figure clé du secteur. Sa fille deviendra correctrice. La version du guide donnée en téléchargement sur le site archive.org est d’assez mauvaise qualité. De toute façon, avec le texte brut ou la piètre qualité de la reconnaissance des caractères on perd absolument tout ce qui fait l’intérêt du livre qui donne beaucoup d’exemples.
    • Sur les formats A. Le site donne les dimensions des feuilles de papier en centimètres et en pixels.

    Les formats numériques (texte et archivage)

    La police

    Postambule

    La prochaine dépêche de la série devrait être moins longue (pas difficile) et portera sur le code avant Unicode. Elle parlera donc aussi de football. Comme toujours, vos suggestions sont appréciées.


    1. MOLINIER A. « Les manuscrits et les miniatures », BnF Gallica: Librairie Hachette, 1892. Disponible sur : BnF Gallica en PDF ou en texte brut. 

    2. L’exemple est reproduit à partir du petit guide de Charles-Lucien Huard La Typographie

    3. Pour rappel, un RFC (Request For Comments) est un document qui définit les normes techniques sur les lesquelles s’appuient le réseau Internet

    4. ANDRÉ Jacques, « Caractères, codage et normalization. De Chappe à Unicode », Document numérique, 2002/3-4 (Vol. 6), p. 13-49. DOI : 10.3166/dn.6.3-4.13-49.

    5. Les formats de texte, archives. 

    6. Wiki de LibreOffice

    7. À noter qu’OpenOffice, compte tenu de son absence d’évolution ne supporte pas la norme ODF 1.3

    8. Office Open XML – Définition

    9. Pour tout dire, mon gestionnaire d’archives Engrampa est incapable d’ouvrir un fichier .docx et l’explication du site, qui n’est pas un site officiel, me semble très touffue. 

    10. Littéralement : « set of macros to let you do many things ».What is the difference between TeX and LaTeX? (en)

    11. Langage de balisage extensible (XML) 1.0, Recommandation du W3C, 10 février 1998. 

    Commentaires : voir le flux Atom ouvrir dans le navigateur

    ❌
    ❌