Traditionnelle période de vœux lors du changement d’année. Voyons ce qui devrait… changera… pourrait éventuellement changer ou non. Donc revenons cette année encore sur nos accomplissements passés et futurs et de ce que nous aimerions voir plus sur notre site préféré.

Cinq personnes se sont prêtées au jeu de cette dépêche pas vraiment de vœux, mais un peu quand même. En vrac dans les accomplissements : hurl, cadran solaire, programmes électoraux, Amstrad CPC, financement européen, Haiku, CV, Transimpressux, visualisation scientifique, XMPP, commentaires de code, docker, menstruation, vélo, documentation, éditeur pixel art, assembleur, OSXP, Smalltalk. L’année qui vient, sur LinuxFr.org, promet d’être (fe)diverse, événementielle, ferroviaire, bureautique, réparable, un peu rouillée, résolue et motivée.

Sommaire

• Benoît Oumph Sibaud
  • Accomplissements, réalisations, progrès de l’année 2024
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
  • Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)
• Ysabeau
  • Accomplissements, réalisations, progrès de l’année 2024
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
  • Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)
• vmagnin
  • Accomplissements, réalisations, progrès de l’année 2024
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
  • Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)
• gUI
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
• PulkoMandy
  • Accomplissements, réalisations, progrès de l’année 2024
  • Ce que je voudrais faire, apprendre ou approfondir en 2025
  • Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)
• Pour finir

Benoît Oumph Sibaud

Accomplissements, réalisations, progrès de l’année 2024

Le retard côté adminsys pour LinuxFr.org se réduit, de même pour celui sur le code (évidemment ça ne va jamais assez vite, c’est le principe) (voir les dépêches sur nos services img et epub). J’ai eu l’occasion de jouer un peu avec Hurl pour des tests HTTP (voir les dépêches précédemment mentionnées et celle sur Hurl 6.0.0) et docker et docker compose, en plus de faire un peu de Go. J’ai pu de nouveau être présent pour le stand et les animations sur place lors de la conférence Open Source eXPerience Paris et c’était bien de revoir d’autres personnes de l’équipe, de notre lectorat, des libristes connus de longue date et des nouvelles personnes (et de goûter la bière de nos 25 ans aussi). Le 28 juin 2024, la politique de minimisation des données mise en place un an plus tôt (pour les 25 ans du site) s’est appliquée pour les comptes déjà fermés préalablement (prochaine étape en juin 2026).

Je suis aussi content de ma dépêche sur le contenu programmatique lors des élections européennes de juin. Je mentionnerais aussi dans les sujets importants la question du programme de financement européen Next Generation Internet (NGI) et la dépêche sur le décès de lunar, un hacktiviste pédagogue.

Ce que je voudrais faire, apprendre ou approfondir en 2025

Déjà dans les reports de 2024, je voudrais m’intéresser au Fediverse et à ActivityPub peut-être, et peut-être à Gemini (le protocole) ? Il y a des travaux en cours sur le service de partage sur les réseaux sociaux share. Par contre j’ai donné moins de conférences en 2024 pour LinuxFr.org et globalement assisté à moins d’événements : donc je réitère l’ambition 2025 de rencontrer plus régulièrement le lectorat ou les personnes contribuant au site ou des publics nouveaux, car c’est appréciable pour le moral et la motivation.

Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)

Je peux reprendre in extenso mon propos de l’année dernière : je serais intéressé d’avoir plus de contenus (idéalement des dépêches) sur la réparation et la réutilisation, sur de l’informatique sobre, sur des sujets qui ne me viendraient pas à l’idée (sérendipité), sur les politiques autour du numérique et des données, sur des retours d’expérience et sur les sujets qui vous passionnent vous.

Ysabeau

Accomplissements, réalisations, progrès de l’année 2024

Quelque chose dont je suis plutôt franchement fière c’est d’avoir parlé d’un sujet typiquement féminin sur LinuxFr.org tout en restant parfaitement dans le thème du site et celui de la Journée internationale des droits des femmes. Le dessin de l’illustration, qui met les points sur les « i » m’a beaucoup amusé. La qualité de l’accueil de la dépêche sur LinuxFr.org et ailleurs m’a ravie. Dans la série réalisations : les portraits que j’ai faits, quelque chose que j’entends continuer, ont été une grande source de connaissances en ce qui me concerne. Pour finir le modèle-tutoriel de CV – Fiche de candidature qui me trottait dans la tête depuis un certain temps.

Concernant les progrès : je pense avoir atteint, en matière d’EPUB, le niveau pour mes besoins. Un jour il faudra que je fasse une dépêche sur ce sujet et sur Sigil. Et j’ai bien progressé avec Inkscape, et même en XML hourra !

Ce que je voudrais faire, apprendre ou approfondir en 2025

Je n’ai pas fini la série Transimpressux, je vais continuer à travailler dessus. En 2024, j’avais aussi pour objectif, désir, de me pencher sur l’informatique et le handicap, l’exploration de l’espace, entre autres sujet, m’en a éloignée. À voir si j’arrive cette année à mieux explorer le terrain. J’ai aussi dans l’idée de rédiger quelque chose sur l’art la manière de faire des modèles pour LibreOffice et le site des extensions de LibreOffice. Parce que ce n’est pas si évident. Peut-être même, si je trouve comment faire, transformer en extension certaines de mes séries de modèles.

Quoi d’autre ? Ah oui et faire des modèles de jouets et miniatures (pour maisons de poupée par exemple) pour Draw et Inkscape qui pourraient être faits soit en imprimant le modèle sur papier et en utilisant des matériaux de récupération (cartons divers) pour la réalisation, soit en utilisant un graveur (découpeur ?) laser. Améliorer peut-être ma connaissance du XML et finir de lire les spécifications de l’ODF peut-être.

Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)

Comme pour l’année dernière, j’aimerais qu’on explore plus les questions de réparabilité très concrètement et sur les plans techniques et juridiques. Il y a aussi la question du handicap et de l’informatique qui mérite d’être plus mise en avant. Et plus de tutoriels.

vmagnin

Accomplissements, réalisations, progrès de l’année 2024

J’ai publié en mars 2024, avec mon coauteur Ali, une bibliothèque en Fortran orienté objet nommée ForColormap qui propose des palettes de couleurs pour la visualisation scientifique. Côté hobbys, j’ai bien progressé dans mes projets musicaux ForMIDI et ForSynth (qui génère des WAV), avec à nouveau l’introduction de l’orienté objet. C’est une façon d’étudier la musique : programmer c’est comprendre. J’ai aussi avancé sur mon projet de cadran solaire ForSundial, le seul que j’ai hébergé pour l’instant sur Codeberg. J’espère avoir le temps un jour d’aller au-delà du prototype en peuplier (il paraît que la découpe laser peut graver du marbre). Ah oui, je me suis aussi acheté une carte Greaseweazle 4.1 pour récupérer le contenu de disquettes des années 80 (en particulier au format Atari ST, non lisible sur PC), mais je n’ai toujours pas eu le temps de faire ce que je voulais. Chacun de ces points pourrait faire l’objet d’un journal, mais le temps, c’est ça le problème…

Sur LinuxFr.org, je n’ai publié que ma dépêche pseudo-périodique « Des nouvelles de Fortran n°6 » pour Noël, ainsi que deux journaux, dont un long qui est la suite de celui de novembre 2021 sur le pulsar iconique CP 1919 et qui parle de beaucoup de choses : histoire de l’informatique, musique électronique, plongée dans les décennies 70 et 80 et ce qu’elles ont à nous dire sur le monde d’aujourd’hui (similarités et différences), etc.

Mais j’ai en fait aussi participé plus ou moins à d’autres dépêches qui m’intéressaient : relecture, discussion ou rédaction. C’est sympa à faire et c’est un peu comme y avoir accès en avant-première. N’hésitez pas à franchir le pas (onglet Rédaction) si ce n’est déjà fait.

Ce que je voudrais faire, apprendre ou approfondir en 2025

Je commence à apprendre le Rust, non pas tellement parce que j’en aurais un quelconque besoin côté professionnel ou côté hobby, mais avant tout pour étudier de nouveaux (pour moi) concepts comme les génériques, les traits, les motifs, la possession et la durée de vie, les fermetures, etc. J’ai emprunté un bon livre : Développez avec Rust traduit récemment chez Dunod. La dernière fois que j’avais vraiment été excité d’apprendre un nouveau langage, c’était avec Python il y a quinze ans (et les expressions régulières en même temps). Après le serpent, je prendrais bien un peu de crabe…

Sinon, j’aimerais bien avoir le temps de faire en 2025 ce que je n’ai pas eu le temps de faire en 2024 :-) Mais j’ai peut-être tort, je devrais peut-être vouloir faire moins de choses pour avoir plus de temps… à ne rien faire (en plus c’est écologique). Être idle.

Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)

Donc des journaux ou dépêches sur Rust :-) J’aime bien aussi ce qui concerne l’histoire de l’informatique, et ce qui sort des clous comme l’histoire des sciences, les arts, en particulier la musique, etc. L’informatique étant quasiment partout, on trouve facilement un prétexte pour parler de n’importe quoi… On pourrait publier des critiques de livres autour de l’informatique ou de la science et la technologie, et pourquoi pas de films ou autres œuvres. Enfin, des bricolages en FabLab peuvent être intéressants.

gUI

Une version très raccourcie pour moi, je voudrais me concentrer particulièrement sur une chose cette année :

Ce que je voudrais faire, apprendre ou approfondir en 2025

De la documentation !

Plusieurs points dans ce sens :

• Améliorer mes commentaires (j’y documente déjà tous les pièges à cons, mais je continue d’avoir du mal à me comprendre quand je déterre des vieux bouts de code)
• Améliorer mes notes perso : aujourd’hui j’utilise nb pour ça. C’est pas mal, mais c’est un peu le foutoir, c’est pas centralisé, bref… peut mieux faire
• Améliorer la doc de mon infra domestique : oui en bon vieux gros Geek c’est pas simple chez moi. Alors déjà quand je dois remettre les mains sur un truc qui tourne sans soucis depuis des années j’ai des gouttes de sueurs, je n’ose imaginer s’il m’arrive quelque chose (eh oui, soyons prévoyants) comment ma famille (pourtant pas des manches) va s’en sortir.
• Quelques autres projets de doc un poil hors-sujet ici (livret d’accueil dans mon association sportive par exemple)

PulkoMandy

Accomplissements, réalisations, progrès de l’année 2024

J’ai continué à travailler sur l’adaptation de vbcc et vasm pour la console de jeux VTech V. Smile. L’assembleur et le compilateur C sont fonctionnels et on peut compiler le système d’exploitation Contiki avec. Le code généré n’est pas du tout optimisé pour l’instant.

J’ai un peu avancé sur mon interpréteur pour les fictions interactives du jeu Lectures Enjeu mais il y a des fonctionnements que je n’arrive pas à comprendre: si je fais fonctionner un jeu, j’en casse un autre :(

J’ai publié une nouvelle version de l’éditeur pixel art GrafX2, il n’y en avait pas eu depuis 2021. Je ne fais plus grand-chose pour ce projet, je pense que le logiciel est assez complet.

Je continue bien sûr à travailler pour Haiku: entre autres sur les dépêches Linuxfr, le navigateur web WebPositive, et le client XMPP Renga. Je n’ai jamais le temps et la motivation de participer autant que je le voudrais.

Enfin, j’ai entrepris la réalisation d'un interpréteur Smalltalk pour Amstrad CPC. Il fonctionne, mais il est beaucoup trop lent.

Et comme il n’y a pas que l’informatique dans la vie, j’ai traversé la France en vélo pour me rendre de Toulouse à Avranches, soit environ 900km en une douzaine de jours. J’ai eu plus de problèmes au retour en train qu’à l’aller en vélo.

Ce que je voudrais faire, apprendre ou approfondir en 2025

Du côté des problèmes techniques: le système de sauvegarde externe de mon serveur auto hébergé est cassé. Il faut que j’investigue les scripts perl fournis par le service de sauvegarde que j’ai choisi (qui a l’avantage d’être vraiment pas cher, et les inconvénients qui vont avec).

Je vais sûrement continuer à travailler sur les projets mentionnés ci-dessus (et quelques autres) et essayer de ne pas en commencer de nouveaux avant d’avoir fini quelque chose. J’ai beaucoup d’idées mais pas le temps pour tout faire.

Je vais essayer de lire les livres que j’ai gagnés grâce à mes contributions à LinuxFr.org et que je n’ai pas tous eu le temps d’ouvrir :(

Je vais également essayer de faire du vélo plus régulièrement, ces derniers temps la motivation m’a beaucoup manqué pour ça.

Des contenus que je voudrais voir plus sur LinuxFr.org (type de contenu, sujet, etc.)

J’aimerais lire des choses sur d’autres systèmes d’exploitation: Linux, BSD, mais aussi Serenity, ReactOS ou Redox OS et sûrement plein d’autres dont je n’ai pas entendu parler.

(mais ce serait en plus des contenus existants sur plein de sujets, et des débats dans les commentaires, qui sont passionnants).

Pour finir

Nous vous souhaitons tout de même la meilleure année possible (on oscille entre être rebelles et conformistes). Et, bien évidemment, n’hésitez pas à « continuer » cette dépêche dans les commentaires.

Et un merci à toutes celles et ceux qui font de LinuxFr.org un site enrichi en sérendipité et surprises.

🎈 Framasoft a 20 ans🎈 : Contribuez pour financer une 21^ième année !

Grâce à vos dons (défiscalisables à 66 %), l’association Framasoft agit depuis 20 ans pour faire avancer le Web éthique et convivial. Retrouvez un focus sur certaines de nos actions en 2024 sur le site Soutenir Framasoft.

➡️ Lire la série d’articles de cette campagne (nov. – déc. 2024)

Graphique présentant l’évolution des visites sur Framadate

Graphique présentant la répartition des pads selon nos instances Framapad (pads annuels, bimestriels, hebdomadaires, semestriels, mensuels et comptes Mypads)

Graphique présentant l’évolution des visites sur Framforms (ça grimpe !)

Graphique présentant l’évolution des visites sur Framacalc

Statistiques de Framateam, notre instance Mattermost

Capture écran du tableau d’accueil de Framagit

Capture écran du tableau d’accueil de Framagit

Graphique présentant l’évolution des visites sur Framacarte

Graphique présentant l’évolution des visites sur Framatalk (remarquez cet énorme pic pendant l’année des confinements !)

Graphique présentant l’évolution des visites sur Framindmap

Framavox – Illustration de David Revoy

Framaspace – Illustration de David Revoy

Statistiques PeerTube des 3 derniers mois de 2023 : instances, utilisateurices, commentaires, vidéos, vues et poids des vidéos

Mobilizon – Illustration de David Revoy

Dorlotons Dégooglisons – Illustration de David Revoy

C’est grâce à vos dons que Espéhef et Ahèmvé font face à Hydrooffice ! Illustration de David Revoy

Illustration de David Revoy – Licence : CC-By 4.0

LDAP Tool Box Service Desk est une interface Web pour gérer les mots de passe et les statuts des comptes d’un annuaire LDAP standard ou d'un annuaire Active Directory. Il est publié sous licence GPL v3.

Ce logiciel sorti en 2020 a bien évolué depuis : système de hook, audit, notifications par courriel, …

La version 0.6 parue début décembre 2024 apporte une innovation majeure : la compatibilité native avec Active Directory.

Active Directory

C'est peut-être un détail pour vous, mais pour les administrateurs Active Directory cela veut dire beaucoup : plus besoin de passer par les outils d'administration Microsoft pour débloquer un compte, les déactiver ou réinitialiser son mot de passe !

Service Desk se connecte désormais directement à Active Directory, autorisant ainsi la délégation d'un certain nombre de tâches de support utilisateur au service helpdesk, sans que celui-ci n'accède directement à l'AD.

OpenLDAP

Nous n'oublions pas bien entendu OpenLDAP, dont la gestion de la politique des mots de passe a bien évolué entre la version 2.4 et la version 2.5.

Service Desk intègre les dernières fonctionnalités de l'overlay policy, en particulier la gestion des dates de début et de fin de validité.

Audit et commentaires

Chaque action effectuée au travers de l'interface peut être tracée dans un fichier d'audit. Afin d'enrichir ces données, il est possible de forcer la saisie d'un commentaire (pour indiquer par exemple le numéro de ticket concerné). Ce commentaire sera visible dans le fichier d'audit.

Hooks

Des scripts peuvent être appelés avant (prehook) ou après (posthook) une action. Ainsi le changement de mot de passe, le déblocage d'un compte, la désactivation d'un compte ou encore la modification des dates de validité peuvent être propagés à d'autres systèmes.

Politique des mots de passe

Le composant visuel utilisé dans Self Service Password qui indiquer dynamiquement si les critères de complexité du mot de passe sont respectés ou non est désormais disponible dans Service Desk, facilitant ainsi la réinitialisation du mot de passe.

Tuxemon Tower 0 est un petit jeu vidéo très sobre. Il est inspiré des jeux Pokémon classiques et consorts, mais il est 100% libre et ne cherche aucunement à être un clone.

Sommaire

• En bref
  • Qu'est-ce que Tuxemon Tower 0 ?
  • Télécharger Tuxemon Tower 0
    • Quelques clients BitTorrent libres
  • Images du jeu
    • Images de cartes
    • Images de combats
    • Images de menus
  • Comment contribuer ?
  • Le droit d'auteur
    • Les licences utilisées
    • Les conséquences
  • Remerciements
• En plus long ?
• Données du jeu
  • Consultation en jeu
  • Documentation HTML
  • Images
    • Liste des créatures
    • Liste des dresseurs et dresseuses
• Annexe : temps et motivation
  • Approximation de l'évolution de la motivation
    • Statistiques de commits par nous pour ce nouveau jeu
    • Statistiques de commits par nous pour Greycess Knight RPG

En bref

Qu'est-ce que Tuxemon Tower 0 ?

Tuxemon Tower 0 est un jeu vidéo de combats en tour par tour. Les combattants peuvent avoir un ou des types, ont des statistiques, et une ou plusieurs capacités. En gagnant assez d'expérience, ils montent de niveau et ainsi deviennent plus forts. Un genre simple et classique, mais efficace.

Et dans le cas de Tuxemon Tower 0, la réalisation est très basique. Cela est vrai autant du point de vue graphique que de celui du moteur. De plus, on accorde qu'on peut parfois juger que l'expérience des joueurs est médiocre (notamment car, hormis être meilleur que nous, vous allez devoir vous fader des combats juste pour avoir un niveau suffisant et on reconnaît qu'il n'y a pas trop d'intérêt ludique à regagner le même combat contre une dresseuse ou commettre un crime contre la biodiversité en enchaînant à gogo les créatures sauvages de la même zone, mais augmenter la vitesse de défilement du texte et garder enfoncé sur le bouton A permet d'écourter le temps de mise à niveau). Mais le jeu est court, donc il est escompté que la découverte et la curiosité qui l'accompagne permettent d'avoir une expérience agréable de ce mini-jeu.

Télécharger Tuxemon Tower 0

Le téléchargement des sources (code, images, etc.), de la documentation générée et des constructions pour certaines plateformes (distributions GNU/Linux et Windows) se fait via BitTorrent à travers un lien magnet. On promeut en effet la décentralisation et le fédéralisme, mais aussi la non-disponibilité permanente. De plus, ça oblige tout le monde à partager le coût (hormis les trackers, certes) et à avoir une copie des sources, tout en étant résilient.

Ce serait sympa de partager pendant l'obtention et aussi après que ce soit fait. Et on prévient : on n'est que rarement à la fois connecté à Internet (on n'a volontairement pas d'accès chez nous) et en mesure de partager via BitTorrent (on ne veut pas faire ça au boulot et il faut que ce soit permis par le réseau), donc ayez de la patience (ou ne vous plaignez pas inutilement). C'est également pour ça qu'on encourage fortement que vous continuez de partager le torrent après l'avoir entièrement obtenu et de préférence sans ratio (puisqu'il n'est pas bien lourd à la vue de la normalité actuelle, et est tout à fait légal, ça ne devrait pas vous être bien problématique).

Quelques clients BitTorrent libres

Au cas où vous n'auriez pas de client BitTorrent (ou un qui soit propriétaire), en voici quelques-uns qui sont libres :

• GNU/Linux, *BSD, Windows et/ou macOS
  • Transmission
  • Deluge
  • KTorrent
  • qBittorrent
• Android
  • LibreTorrent
  • BiglyBT

Images du jeu

Images de cartes

Images de combats

Images de menus

Comment contribuer ?

Avant d'éventuellement contribuer, n'oubliez pas plutôt en priorité de faire des choses plus importantes. En effet selon nous, mieux vaut s'activer pour l'émancipation sociale universelle et tendre vers une société écologique que de contribuer à un jeu.

1. Pour nous, la meilleure manière de contribuer est de mettre à disposition des sprites pour des créatures et des dresseurs. En effet, nous sommes très mauvais pour produire ça et cela ajouterait de la diversité bienvenue (pendant que celle sur Terre s'effondre…). Si ça vous branche, faites-le en respectant le style des actuels, avec une taille adéquate (64×64 et/ou 56×56 et/ou 48×48), et de préférence en faisant l'avant et l'arrière (car avec juste l'avant on ne peut pas jouer la créature ou la personne dresseuse mais juste l'affronter), voire en vous restreignant à 4 couleurs (c'est là la contrainte ultime, mais qui serait utile pour économiser de l'espace et deviendra nécessaire si un jour un port sur GameBoy Color est fait) et alternativement c'est déjà ça si ça ne dépasse pas la barre des 8 (qui va nous servir de transition entre 16 et 4, tout en permettant de réduire l'usage mémoire avec une petite astuce ou de la compression plus poussée que nous ne ferons probablement pas).
2. Nous n'avons pas l'intention de gérer une communauté autour de ce jeu. C'est pourquoi nous n'avons pas mis le code source sur une forge et nous ne comptons pas le faire. Rien ne vous empêche toutefois de faire une version dérivée et de la publier, peut-être que nous irons y piocher des trucs en vous créditant si nous en avons connaissance.
3. Bien sûr, si vous voulez que nous intégrions peut-être un jour une contribution, veillez à la mettre sous une licence compatible quand vous n'y êtes pas de toute façon obligé par le gauche d'auteur. Utilisez donc une licence libre, avec de préférence la GNU AGPLv3+ pour le code source et la Creative Commmons BY-SA v4.0 pour le reste.
4. Mais où mettre ce que vous produisez ? Ça vous regarde. Mais, pour que ce soit visible, le wiki du projet Tuxemon est un bon endroit ou vous pouvez faire un commentaire ci-dessous (pointant par exemple vers votre dépôt sur OpenGameArt).
5. Si vous vous y connaissez en portage ou en packaging pour votre système favori, n'hésitez pas à faire un joli paquet pour le jeu et à tenter honnêtement de le faire officiellement intégrer. Toutefois, cela ne vaut pas pour Apple iOS, Google Play, Microsoft Store, Steam de Valve, Origin d'Electronic Arts, et consorts.
6. Évidemment une autre forme de contribution est tout simplement de faire la promotion du jeu. Parlez-en !
7. Enfin, il existe un moyen rudimentaire : partager le contenu du torrent, pour qu'il soit disponible le plus de temps possible. En effet, nous sommes très loin d'être en permanence avec un accès à Internet et nous n'ouvrons pas systématiquement notre client BitTorrent favori quand nous le sommes.

Le droit d'auteur

Les licences utilisées

• La très vaste majorité du code source est sous la licence GNU AGPL en version 3.0 ou plus. Le faible reste est dans le domaine public (via une version très légèrement augmentée de la licence GNU All-Permissive ou FSFAP dans la nomenclature SPDX).
• Les sprites 16×16 sont dans le domaine public (via la licence Creative Commons 0).
• Les sprites 64×64 ont été faits par de multiples personnes et sont donc sous de multiples licences libres.

Les conséquences

• Pour le code sous GNU AGPL, c'est avec gauche d'auteur contaminant, y compris pour la fourniture par réseau (c'est l'amélioration par rapport à la GNU GPL). Si vous distribuez une version modifiée, vous devez donc en distribuer le code source et ce sous une licence compatible (le plus simple est d'utiliser la même licence et à notre connaissance c'est la seule pour du déjà existant, mais vous pouvez utiliser la GPLv3 pour du nouveau code mis dans un nouveau fichier).
• Vous pouvez faire ce que vous voulez du code sous licence GNU All-Permissive et de tous les sprites 16×16.
• Si vous utilisez un ou des sprites 64×64, vous devez au moins en créditer la ou les personnes autrices et mentionner la licence. Pour certaines, vous devez partager sous les mêmes conditions même si modification(s) (de par le gauche d'auteur de la Creative Commons BY-SA et de la GNU GPL).

Remerciements

• le projet Tuxemon originel, pour le concept et le rassemblement des sprites 64×64 et la création d'un certain nombre
• OpenGameArt et Kenney, pour les sprites 16×16
• le projet GNU, pour notamment sa « philosophie » et ses licences, ainsi que GCC
• GNU make et CMake, pour l'orchestration de la compilation et des tests
• Trisquel GNU/Linux et Debian GNU/Linux, les deux systèmes d'exploitation utilisés
• GDB et Valgrind, pour avoir bien aidé à déboguer et résoudre des problèmes de mémoire
• check, pour des tests automatiques d'exécution
• Clang, pour ses messages complémentaires à GCC
• cppcheck et splint, ainsi que KWStyle, pour des tests statiques complémentaires aux compilateurs
• toutes celles et ceux qu'on a oubliés (moyen facile de demi-esquive !)

En plus long ?

Le comité éditorial de LinuxFr.org a jugé inappropriée la version longue qui était prévue et qui lui a été soumise. De plus, il a suggéré de feuilletonner l'annonce d'origine. Mais cela ne correspond pas à notre vision éditoriale et plus généralement notre vision anthropologique (le brouhaha communicationnel nous apparaît comme néfaste et donc à ne surtout pas alimenter), et nous n'avons de toute façon pas envie d'y passer du temps (il y a pour nous bien plus important que ce petit jeu vidéo, dont la réalisation est plus pour nous un plaisir coupable qu'autre chose, à fortiori dans une phase très nette de fascisation et d'écocide).

Néanmoins l'annonce d'origine, qui contient bien plus d'explications, reste disponible. Dans le torrent, il y a les sources (sources.tar.xz) et dans celle-ci il y a l'annonce prévue à la base (news/fr/version-1-0-0_annonce.md). Et si vous voulez la publier ailleurs (en mentionnant que nous en sommes à l'origine et en différenciant bien toute modification), en entier ou sous forme partielle, elle est sous licences libres (vous pouvez choisir celle qui vous convient le mieux) avec gauche d'auteur : Creative Commons BY-SA 3.0, Creative Commons BY-SA 4.0 et GNU GPL 3.0.

Données du jeu

Consultation en jeu

Dans le menu de lancement, proposant de démarrer une nouvelle partie ou d'en charger une existante, appuyez sur Start (ou plutôt l'un des boutons qui y correspond si vous n'utilisez pas une manette ou qu'elle n'est pas reconnue ou pas bien). Cela vous fera changer de menu. Vous aurez alors une entrée « Explorer les données ». Ce n'est pas parce que ça existe que c'est exhaustif.

Documentation HTML

Dans le torrent, avec les sources et les constructions, il y a de la documentation sous forme de fichiers HTML, que vous pouvez consulter avec un navigateur web. Vous pouvez aussi la regénérer depuis les sources. Comme pour la consultation en jeu, ce n'est pas nécessairement exhaustif, mais c'est déjà ça.

Images

Liste des créatures

Liste des dresseurs et dresseuses

Annexe : temps et motivation

Au début d'un projet personnel, la motivation est souvent grande. Mais tant qu'il n'y a pas quelque chose de finalisée, il est à priori courant que la motivation tende à décroitre. En tout cas, c'est notre cas.

C'est en partie pour cela que le jeu est très simple (système ultra-basique pour les cartes, pas de possibilité d'esclavagir, pas de statut, pas de possibilité de manipulation par le joueur/joueuse d'objets non-visuels, pseudo-aléatoire en guise de non-intelligence artificielle, etc.). L'autre grosse partie de l'explication est la volonté de faire de la basse technologie (d'où entre autres que ce soit graphiquement en niveaux de gris, malgré des sprites avec des couleurs au-delà de ce spectre) et la restante est l'ajout de complexité qui nuise à l'expérience de la mécanique du jeu en ajoutant du « bruit », mais ce n'est là pas le sujet.

Venir reprocher ou se plaindre de la trop grande simplicité du jeu (qu'il aurait fallu qu'il y ait ceci et cela, etc.) peut être en soi une critique pertinente. Néanmoins, ça ferait totalement fi de l'aspect humain en ce qui concerne la production. En effet, si le jeu n'était pas aussi basique, il ne serait probablement jamais sorti de par la baisse de motivation.

C'est pourquoi le jeu est volontairement très simple. Mais c'est une fin en soi et une base. Tout ce qui a été fait pour la version 1.0.0 de ce jeu ne sera plus à faire pour une ou des éventuelles versions améliorées et un ou des éventuels autres jeux exploitant tout ou partie de ce qui a été réalisé pour celui-là.

Approximation de l'évolution de la motivation

Dans le cadre du développement de ce jeu, on utilise git, un logiciel de gestion de version. Tous les changements y sont consignés et datés. À partir des informations qu'il a enregistrées, il est donc possible d'avoir une idée de l'évolution de la motivation.

Toutefois, on ne va pas vous livrer le dépôt git (et on a expliqué pourquoi). Vous n'en aurez donc ci-après qu'une vue fort approximative, dont la génération a été faite par git-bars.

Il fournit une vue par mois du nombre de commits. C'est donc très approximatif. En effet, un commit peut avoir une taille très variable et être pour des changements importants ou mineurs. Néanmoins, ça donne tout de même une image plutôt réaliste de l'évolution de notre motivation.

On peut notamment bien voir que les débuts sont des périodes fastes. Pour début 2023, on peut constater que c'est assez peu garni, ce qui s'explique par la contre-réforme des retraites. Mais ça montre aussi un biais : en mars et en avril 2023, on n'a fait que des petits trucs pas bien importants, mais ça a engendré pas mal de commits.

Statistiques de commits par nous pour ce nouveau jeu

2024-11  61   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-10  52   ▀▀▀▀▀▀▀▀▀▀▀
2024-09  45   ▀▀▀▀▀▀▀▀▀▀
2024-08  77   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-07  19   ▀▀▀▀
2024-06  34   ▀▀▀▀▀▀▀
2024-05  62   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-04  126  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-03  59   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-02  96   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-01  89   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-12  52   ▀▀▀▀▀▀▀▀▀▀▀
2023-11  78   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-10  117  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-09  224  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-08  106  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-07  87   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-06  56   ▀▀▀▀▀▀▀▀▀▀▀▀
2023-05  106  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-04  92   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-03  60   ▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-02  10   ▀▀
2023-01  19   ▀▀▀▀
2022-12  34   ▀▀▀▀▀▀▀
2022-11  80   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-10  87   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-09  106  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-08  88   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-07  138  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-06  85   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-05  50   ▀▀▀▀▀▀▀▀▀▀▀
2022-04  28   ▀▀▀▀▀▀
2022-03  121  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-02  131  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-01  144  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-12  133  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-11  81   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-10  26   ▀▀▀▀▀
2021-09  35   ▀▀▀▀▀▀▀
2021-08  45   ▀▀▀▀▀▀▀▀▀▀
2021-07  85   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-06  5    ▀
2021-05  18   ▀▀▀▀
2021-04  55   ▀▀▀▀▀▀▀▀▀▀▀▀
2021-03  79   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-02  112  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-01  60   ▀▀▀▀▀▀▀▀▀▀▀▀▀

Statistiques de commits par nous pour Greycess Knight RPG

Greycess Knight RPG est la base de ce nouveau jeu. Il part donc du même dépôt git. Puisque des changements sont valables pour les 2 jeux, on les fait dans Greycess Knight RPG, ce qui occasionne des commits de fusion dans le nouveau jeu. De plus, en soustrayant les nombres de commits par mois de Greycess Knight RPG à ceux du nouveau jeu, on peut avoir le nombre de commits qui touchent aux changements nécessaires au nouveau, ou du moins en partie puisqu'on fait parfois le changement dans le nouveau jeu avant de le mettre aussi dans l'ancien ou le (quasi-)même changement dans les 2 pour faciliter la fusion. C'est pour ça qu'on met ci-après les statistiques pour Greycess Knight RPG.

2024-11  17   ▀▀▀▀▀▀▀
2024-10  9    ▀▀▀▀
2024-09  4    ▀
2024-08  20   ▀▀▀▀▀▀▀▀
2024-07  1    
2024-06  8    ▀▀▀
2024-05  15   ▀▀▀▀▀▀
2024-04  34   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2024-03  3    ▀
2024-02  10   ▀▀▀▀
2024-01  12   ▀▀▀▀▀
2023-12  16   ▀▀▀▀▀▀▀
2023-11  15   ▀▀▀▀▀▀
2023-10  13   ▀▀▀▀▀
2023-09  29   ▀▀▀▀▀▀▀▀▀▀▀▀
2023-08  26   ▀▀▀▀▀▀▀▀▀▀▀
2023-07  25   ▀▀▀▀▀▀▀▀▀▀▀
2023-06  26   ▀▀▀▀▀▀▀▀▀▀▀
2023-05  25   ▀▀▀▀▀▀▀▀▀▀▀
2023-04  35   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2023-03  27   ▀▀▀▀▀▀▀▀▀▀▀▀
2023-02  4    ▀
2023-01  3    ▀
2022-12  9    ▀▀▀▀
2022-11  22   ▀▀▀▀▀▀▀▀▀
2022-10  15   ▀▀▀▀▀▀
2022-09  14   ▀▀▀▀▀▀
2022-08  27   ▀▀▀▀▀▀▀▀▀▀▀▀
2022-07  44   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-06  14   ▀▀▀▀▀▀
2022-05  16   ▀▀▀▀▀▀▀
2022-04  6    ▀▀
2022-03  22   ▀▀▀▀▀▀▀▀▀
2022-02  33   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2022-01  54   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-12  92   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-11  81   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-10  26   ▀▀▀▀▀▀▀▀▀▀▀
2021-09  35   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-08  45   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-07  85   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-06  5    ▀▀
2021-05  18   ▀▀▀▀▀▀▀▀
2021-04  55   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-03  79   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-02  112  ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
2021-01  60   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

Par ailleurs, comme vous pouvez le voir, ça a bougé du côté de Greycess Knight RPG. Une version 1.0.2 est en cours. Mais du point de vue de l'expérience de jeu, elle n'apporte rien ou presque. Ce sera une mise à jour technique : elle consistera essentiellement en une amélioration du code source (de diverses manières et à divers endroits) et en une réduction par 3 de la taille du binaire sans la bibliothèque SDL2 statiquement liée (ce qui l'amènera à environ 250 ko grâce à la correction d'une erreur stupide).

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
• Côté code Ruby on Rails
• Côté epub
• Historique
• Évolutions récentes
  • Dockerfile
  • La suite de tests
• Les problématiques restantes
• Conclusion ?

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 :

• le besoin de pouvoir choisir l’hôte (histoire de ne pas toujours tester sur la production)
• mieux gérer certaines erreurs comme les réponses inattendues
• corriger les zip sans extension unix, le logo en couverture
• documenter les cas pouvant être mieux gérer : image trop grande, non récupérable, format inconnu, etc. en fournissant les tests en attendant la correction

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.

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 à img, un code sous AGPLv3.

Elle est née d’une envie personnelle d’expliquer, documenter et montrer ce qui a été fait sur le cache d’images de LinuxFr.org, complétée d’une demande d’un « article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… ».

Sommaire

• Des images sur le site
• Buts du cache d’images
• À l’utilisation
• Côté code Ruby on Rails
• Côté img
• Historique
• Évolutions récentes
  • Dockerfile
  • La suite de tests
  • L’audit interne
• Le grand nettoyage
• Les problématiques restantes
• Conclusion ?

Des images sur le site

LinuxFr.org vous permet d’utiliser des images externes dans les contenus et commentaires du site. Ces images sont incluses en syntaxe markdown avec ![description textuelle](adresse "titre optionnel") (soit en saisissant directement du Markdown, soit en cliquant sur l’icône d’ajout d’image dans l’éditeur). Profitons-en pour rappeler que pour utiliser une image sur LinuxFr.org, vous devez vous assurer de respecter sa licence.

Nous vous encourageons donc à utiliser des images sous licence libre et à citer les auteurs (c’est même obligatoire pour les licences CC-by et CC-by-sa). Cette citation est tirée de la dépêche d’annonce Un nouveau reverse-proxy cache pour les images externes sur LinuxFr.org de 2012.

Il est aussi recommandé de mettre une vraie description textuelle, qui finira dans l’attribut alt de la balise img utilisée pour l’accessibilité ou si l’image ne peut être chargée. Il peut être utile de lui donner un titre qui apparaîtra l’autre du survol de l’image à la souris par exemple.

Exemple :

![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png "L’actualité du logiciel libre et des sujets voisins (DIY, Open Hardware, Open Data, les Communs, etc.), sur un site francophone contributif géré par une équipe bénévole par et pour des libristes enthousiastes.")

Buts du cache d’images

Les raisons évoquées à la mise en place de img (sans ordre particulier) :

• la sécurité : si une image externe n’est servie qu’en HTTP (en clair donc) et est appelée au milieu d’une page LinuxFr.org elle-même servie en HTTPS, alors le navigateur va râler sur le mélange des genres. img permet de servir toutes les images identiquement (par exemple en HTTPS, et avec le certificat de LinuxFr.org, via le serveur frontal devant img). À noter que ces images ne sont pas servies directement depuis le domaine principal linuxfr.org mais depuis un sous-domaine img.linuxfr.org pour éviter que le JavaScript embarqué dans les images en SVG puisse servir de vecteur d’attaque contre le site.
• la protection de la vie privée des personnes visitant LinuxFr.org : seul LinuxFr.org voit les informations en provenance de leur navigateur (dont l’adresse IP). Les équipes d’administration des différents sites ne les voient plus (elles voient l’adresse IP du serveur LinuxFr.org).
• une meilleure gestion du trafic : au lieu d’envoyer tout notre public chercher individuellement chaque image, LinuxFr.org la récupère une fois et la rend disponible. Si le site externe fournissant l’image est un serveur à faibles ressources (liaison ADSL avec faible débit montant par exemple), la mise en cache permet de garantir qu’il ne recevra qu’un faible volume de requêtes (la récupération se faisant initialement toutes les 10 min tant que des demandes arrivent, le cache expirant après 10 min).
• la conservation des images : les images incluses depuis des sites externes peuvent ne plus être disponibles (l’entité a disparu, le serveur a été arrêté, le domaine a été perdu, l’adresse a changé, etc.). Nous avons donc un mécanisme de cache pour que nous puissions continuer à servir une image même si elle devient indisponible.

Parmi les conséquences de cette implémentation initiale, on peut citer :

• si le fichier est changé sur le serveur distant (modifié, converti dans un autre format), l’ancien fichier est servi jusqu’à la prochaine récupération et le nouveau fichier ne sera servi qu’à la prochaine récupération ;
• si le fichier est supprimé sur le serveur distant, l’image ne sera plus servie après la prochaine récupération (car le serveur a répondu que l’image n’existe plus) ;
• il est possible de modifier l’image au passage : les images d’avatar sont retaillées pour une hauteur de 64 pixels par exemple ;
• il est possible de bloquer des images : les images problématiques (pub/spam, contenus pour adultes, images injurieuses, etc.) peuvent être bloquées et ne plus être servies ;
• par ailleurs img n’accepte de servir que les images connues de LinuxFr.org dont le poids fait moins de 5 MiB.

À l’utilisation

Lors de l’écriture d’un commentaire ou d’un contenu sur LinuxFr.org, une personne va ajouter une image externe via la syntaxe Markdown, par exemple ![Logo LinuxFr.org](https://linuxfr.org/images/logos/linuxfr2_classic_back.png)

Ce qui donne à l’affichage :

Et côté code HTML :

<img src="https://linuxfr.org/images/logos/linuxfr2_classic_back.png" alt="Logo LinuxFr.org">

OK, mauvais exemple ce n’est pas une image externe, puisqu’elle est hébergée sur LinuxFr.org justement. Prenons un autre exemple ![April - Campagne d’adhésion](https://april.org/campagne-2024/relais/banniereCampagneApril.svg).

Ce qui donne à l’affichage :

Et côté code :

<img src="//img.linuxfr.org/img/68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667/banniereCampagneApril.svg" alt="April - Campagne d’adhésion" title="Source : https://april.org/campagne-2024/relais/banniereCampagneApril.svg">

Donc on sert l’image via le sous-domaine img.linuxfr.org. On peut aussi noter le titre rempli automatiquement avec la source. Expliquons la nouvelle adresse :

• // on sert en https si la page est en https et en http si la page est en http (c’est plutôt un oubli qu’autre chose, vu que le site est uniquement en https)
• img.linuxfr.org on sert depuis un sous-domaine du site
• 68747470733a2f2f617072696c2e6f72672f63616d7061676e652d323032342f72656c6169732f62616e6e6965726543616d7061676e65417072696c2e737667 est la version en texte-vers-hexadécimal de l’adresse d’origine (68 pour h, 74 pour t (deux fois), 70 pour p, etc.). Il existe des sites et des outils en local pour faire cette conversion, mais cela ne concerne pas la simple utilisation du site.
• banniereCampagneApril.svg on met à la fin le nom du fichier pour être sympa si vous voulez sauver l’image en local avec un nom plus explicite

Ceci était le cas où tout se passe bien, comme prévu, comme le voulait la personne qui voulait utiliser une image externe.

Voyons maintenant ce qui se passe dans le cas pas si rare où la personne a donné une adresse d’image invalide, une adresse ne pointant pas vers une image vers autre chose (cas extrêmement fréquent), une image trop grosse (plus de 5 MiB), etc. Il se passe la même chose côté code, mais côté affichage, pas d’image, et on voit seulement le texte alternatif dans son navigateur. Dans les coulisses, img a répondu 404, cette adresse n’est pas disponible.

On note donc qu’une même image servie en http:// ou en https:// aura une adresse convertie en hexadécimal différente, donc sera vue comme une autre image par img. Même chose si le serveur externe accepte des adresses sans tenir compte de la casse, ou si on rajoute des paramètres dans l’adresse comme « ?mot_magique=merci ».

Côté code Ruby on Rails

Un contenu ou commentaire est en cours de création et une image externe a été mentionnée. Le code de gestion des images va vérifier que l’image est déclarée dans redis (créer l’entrée img/<adresse> avec adresse l’adresse de l’image en clair, ajouter un champ created_at avec l’horodatage, ajouter l’adresse dans la liste des dernières images img/latest) et renvoyer l’adresse via img.

Le code peut aussi modifier le champ status d’une image dans redis pour mettre ou enlever un blocage (valeur Blocked) par l’équipe du site, et l’ajouter/enlever de la liste des images bloquées img/blocked.

Côté img

Les schémas dans la documentation du service img explicitent les possibilités et les comportements.

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 peut envoyer des requêtes GET /img/<adresse_en_hexa> or GET /img/<adresse_en_hexa>/<nom_de_fichier> pour les images, et GET /avatars/<adresse_en_hexa> ou GET /avatars/<adresse_en_hexa>/<nom_de_fichier> pour les avatars.

En se limitant aux requêtes légitimes, le comportement de img est le suivant :

• l’adresse demandée a été précédemment déclarée (dans redis par la partie code Ruby On Rails) sinon il répond 404 ;
• l’adresse demandée n’est pas bloquée par l’équipe du site sinon il répond 404 ;
• l’adresse est déjà dans le cache disque, alors il renvoie l’image ;
• l’adresse n’est pas dans le cache disque et la récupération échoue, il renvoie 404 (et va noter temporairement l’échec dans img/err/<uri>) ;
• l’adresse n’est pas dans le cache disque et la récupération a lieu (noté temporairement dans img/update/<uri>): si le serveur répond positivement à la demande, avec une image comme attendue, pas trop volumineuse, alors on la met en cache disque. Si c’est un avatar, on peut retailler l’image. On aura des champs supplémentaires stockés type avec la nature de l’image (en-tête Content-Type), checksum avec un hachage SHA1 et etag avec la valeur ETag (entête ETag).

Le cache est rafraîchi régulièrement.

img est un binaire statique en Go. Il offre des options pour définir le couple adresse:port d’écoute, pour définir où envoyer les logs, pour se connecter à une base redis, pour définir le répertoire du cache disque, pour choisir le User-Agent qui sera utilisé pour les requêtes externes, pour définir l’avatar qui sera renvoyé par défaut, et la possibilité de le lancer uniquement en mode audit interne pour vérifier la cohérence et l’état des données et des fichiers.

Dans les logs on va trouver des infos comme :

2024/10/20 20:39:24 Status code of http://example.invalid/exemple1.png is: 404
2024/10/20 20:39:24 Fail to fetch http://example.invalid/exemple1.png (serve from disk cache anyway)
2024/10/20 20:44:12 Fetch http://example.invalid/exemple2.png (image/png) (ETag: "be5e-4dba836030980")
2024/10/20 20:44:12 http://example.invalid/exemple3.png has an invalid content-type: text/html;charset=UTF-8
2024/10/20 20:44:12 Fail to fetch http://example.invalid/exemple3.png (serve from disk cache anyway)

Ici l’exemple 1 est déjà en cache et peut être servi même si on échoue à le récupérer à ce moment-là. L’exemple 2 vient d’être récupéré. L’exemple 3 a désormais une adresse invalide (qui renvoie une page HTML au lieu d’une image) mais il existe en cache une image précédemment récupérée.

Historique

img a été créé par Bruno Michel en 2012. Adrien Kunysz amène 5 commits en novembre 2013, mais globalement Bruno est le seul à travailler dessus (43 commits) jusqu’en 2018. img fait le job et il n’est pas besoin d’y retoucher trop souvent.

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 img 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 img (2022-2024), car a priori ce n’est pas le composant le plus compliqué du site (il vit dans son coin, il offre une interface, c’est du Go, donc on a un binaire seulement à gérer).

Étape 1 : je vais commencer par ajouter un Dockerfile permettant de recompiler img 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.

Étape 2 : 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 (avec des images redis et nginx), 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 d’images, le test de vie, des appels erronés (mauvais chemin, mauvaise méthode, etc). 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.

Étape 2,5 : l’avatar par défaut renvoie sur le site de production, y compris sur les tests en développement en local et sur le serveur de test du site. J’en profite pour ajouter un paramètre pour cela (et cela permettra de passer du PNG au SVG par défaut).

Étape 3 : encore une fois essayons de simplifier la vie d’hypothétiques personnes contributrices. Une petite modification pour que hurl et redis soient fournis via docker-compose et ne soient plus nécessaires sur le poste de développement.

Étape 4 : il est temps de documenter plus le fonctionnement. J’avais déjà décrit les infos stockées dans redis, mais pour comprendre le système de cache, autant fournir des diagrammes pour illustrer ce qui se passe lors d’une requête et comment on passe d’un état à un autre. C’est aussi l’occasion de compléter la suite de tests en ajoutant des tests avant et après expiration du cache, histoire de pouvoir documenter ces cas précis.

Étape 5 : en cas d’échec de récupération, une image était indisponible jusqu’à la prochaine récupération (donc potentiellement pendant 10 min). Autant servir l’ancienne version en cache lorsque cela se produit : je modifie le code et les tests en conséquence.

Étape 6 : je sais que certaines images ont été perdues, que des adresses d’images ont toujours été erronées, que des contenus et commentaires ont été supprimés et qu’il n’y a donc plus lieu de garder les images associées. Je décide d’implémenter dans img un audit interne qui indiquera si des anomalies sont présentes dans redis, si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image. Et j’ajoute cet audit dans la suite de tests.

Étape 7 : 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 minimale Alpine
• de l’utiliser pendant la construction en prenant la liste des dépendances, en les téléchargeant, en prenant l’unique fichier source img.go et en le compilant statiquement avec l’option pour retirer les chemins de compilation
• de rechercher les éventuelles vulnérabilités avec govulncheck
• d’ajouter le paquet tzdata pour avoir les définitions fuseaux horaires (nécessaire pour les conversions de/vers GMT pour les entêtes type Last-Modified).
• de repartir d’une base Alpine en y mettant les définitions de fuseaux horaires 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 img, et démarrer le redis et le nginx préconfigurés pour les tests. Si tout va bien, on attend, et au bout d’un moment il s’affiche :

linuxfr.org-img-test_1  | All tests look good!
tests_linuxfr.org-img-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 redis qui sera utilisée (stockage géré par docker), l’image nginx qui sera utilisée avec sa configuration et ses fichiers à servir pour les tests, l’image img et son paramétrage (dont l’accès au redis et au nginx) ainsi que le répertoire du cache et enfin l’image de la suite de tests qui est construit avec son Dockerfile, prévue pour faire du Docker-in-Docker et avoir accès au cache img et aux fichiers nginx.

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), coreutils, docker et xxd (pour les conversions texte vers hexadécimal). 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, une image destinée à être bloquée, des images dans divers formats, une image très grande en pixels mais pas trop en octets, une image trop grande en octets, et un avatar à servir par défaut.

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

• le test de vie et les chemins hors img/ et avatars/
• les tests sur les avatars : adresse valide ou invalide, image inexistante, bon et mauvais types, comportements sur les différents codes HTTP et sur une boucle de redirection infinie
• les tests sur les images (découpés en trois parties, la partie initiale, la partie entre la récupération initiale et l’expiration du cache et enfin la partie après la récupération et l’expiration du cache.

Vient enfin le script shell qui pilote le tout :

• on définit les variables pour les cibles IPv4/IPv6 et les binaires redis et img que l’on veut utiliser dans les autres conteneurs Docker
• on liste les images dans différentes catégories :
  • celles qui vont échouer et ne comporteront donc qu’une entrée dans redis sans rien dans le cache disque (avec sous-catégories possibles bloquées/non-bloquées)
  • les images devant être en erreur
  • les images qui iront normalement dans le cache
• on prépare des images qui seront altérées plus tard
• on purge le cache sur disque, on nettoie redis et on déclare toutes nos images comme le faire le code Ruby on Rails. Certaines sont déclarées bloquées pour les tests.
• on lance les premiers tests (en IPv4 et IPv6, en HTTP 1.1 et en HTTP 2.0)
• on modifie certaines images pour simuler un changement sur le serveur externe, une suppression sur le serveur externe ou un blocage par l’équipe de site
• on lance les tests post-récupération initiale mais avant l’expiration du cache (toujours avec toutes les variantes)
• on force l’expiration du cache
• on lance les tests post-expiration du cache (toujours avec toutes les variantes)
• si on est arrivé jusqu’ici, c’est qu’on a passé tous les tests Hurl, alors maintenant on recompte ce que l’on a dans redis et sur disque et on vérifie si ça correspond à nos attentes
• on nettoie les images mises volontairement en échec
• on lance le test d’audit interne qui doit nous dire que tout va bien
• si on est arrivé jusque-là on écrit que tout va bien et on déclenche un sourire de satisfaction.

L’audit interne

L’objectif est de vérifier la cohérence des données dans redis, si des images sont indisponibles ou si des entrées dans le cache disque ne correspondent plus à aucune image.

Le binaire d’img peut donc être appelé en mode audit et lancer des contrôles internes.

D’abord il collecte la liste des fichiers dans le cache disque.

Ensuite il vérifie que toutes les images listées dans les dernières images (img/latest) existent comme entrées individuelles.

Puis il vérifie s’il existe des images bloquées (il râlera s’il y en a) et si chacune existe comme entrée individuelle le cas échéant.

Ensuite on parcourt tous les entrées individuelles d’images :

• on râle si on tombe sur une entrée img/updated/ ou img/err/ sans date d’expiration
• on râle si on tombe sur une entrée img/ sans champ created_at, sans type ou d’un type inconnu, sans checksum, avec un statut inconnu, une image bloquée non présente dans les images bloquées, un champ inconnu, une présence inattendue dans le cache disque, etc. Et on marque les images que l’on a vu passer comme attendu dans le cache.
• on râle sur tous les fichiers du cache restants (ne correspondant à aucune image)
• si on a râlé, on renvoie 1, sinon 0

Le grand nettoyage

img a fonctionné pendant 12 ans en production : il a rencontré des bugs, des comportements inattendus, des contenus et commentaires ont été supprimés ou réédités, etc. Il est donc probable qu’il y ait besoin d’aller dépoussiérer un peu tout cela et de retirer ce qui est inutile.

Les traces du grand nettoyage sont d’abord visibles dans la rétrospective de la première quinzaine de septembre 2024 :

• une « image » sur sept présente un souci (n’est pas une image, adresse invalide, trop grosse, etc.) et n’est donc pas dans le cache sur disque (ce qui a conduit à pas mal de taf sur la partie gestion des images)
• les types de contenu (Content-Type) en provenance de sites variés et divers, c’est quelque chose… entre les « image/JPEG » ou « image/PNG » en majuscules parce que, les charset=utf-8 ou UTF-8 ou… sur du binaire, les name= qui ne sont pas dans la norme… Wikimedia renvoie aussi du profile="https://www.mediawiki.org/wiki/Specs/SVG/1.0.0" (pareil ça semble en dehors de tout standard).

D’abord j’attaque le sujet la fleur au fusil en me disant que ça va passer crème, je fais un joli tableau qui résume l’état initial :

                              img/<uri>   img/updated/<uri>   img/err/<uri>   blocked
total                           25565 -21       634               160            5

no created_at                      23 -23         0                 0            0
created_at                       2857 -3          0                 5            1
created_at+type                   222             0                 0            0
total not in cache               3104 -26         0                 0            0

created_at+type+checksum(+etag) 22463 +5        634               155            4

files in cache                  22778 +5

Donc on a officiellement 25 565 images, mais 23 sont mal créées (état théoriquement impossible hors race condition), 222 sont incomplètes (état théoriquement impossible race condition), 22 463 sont attendues en cache et on a 22 778 fichiers dans le cache. Ça part mal. Je nettoie en premier le plus facile (on voit le delta +/- de mes corrections). Et on arrive à une situation où une image sur sept présente alors un souci et il faut gérer un grand volume de corrections à faire.

Parmi les soucis on trouve des types de contenus inattendus (image/PNG ou image/JPEG avec majuscules, image, des images binaires annoncées avec un charset, des types invalides comme image/jpg au lieu de image/jpeg, etc), des erreurs de notre lectorat (mauvais lien, mauvais copier-coller, lien vers une page web au lieu d’une image), mais aussi des espaces insécables et autres blancs inopportuns, des guillemets convertis, des doubles scheme (http://https:// ou http://file://).

Après cela se cache une autre catégorie encore plus pénible : les images que l’on a en cache, mais qui ne sont plus utiles au site : par exemple celles qui étaient dans des contenus ou commentaires supprimés (notamment le spam), celles qui étaient dans des commentaires ou contenus réédités depuis, etc.

Un problème connu est devenu vite pénible : on n’a pas d’association entre les images externes et les contenus/commentaires concernés. Donc il faut d’abord extraire la liste de toutes les déclarations d’images externes des 12 tables SQL où l’on peut trouver des images et des avatars, sous forme HTML ou Markdown.

Ensuite il faut sortir toutes les entrées dans redis et regarder si on les retrouve en clair ou converties en hexadécimal dans l’extraction SQL.

Et par sécurité on fera une double vérification pour celles détectées en erreur, en relançant une recherche en base (attention à la casse dans la recherche texte).

Au final, on peut supprimer des milliers d’entrées redis et de fichiers dans le cache.

Et un jour l’audit dit :

Connection 127.0.0.1:6379 0
2024/10/19 12:11:21 Sanity check mode only
2024/10/19 12:11:37 Files in cache: 17926
2024/10/19 12:11:39 Total img keys in redis: 18374
OK

Ça aura pris un mois et demi (l’audit a été fusionné le 8 septembre 2024), certes pas en continu, mais ça a été long et guère palpitant de faire ce grand ménage. Et j’ai refait une seconde passe du traitement complet la semaine d’après pour vérifier que tout se passait correctement et que les soucis résiduels après tout ça étaient minimes ou nuls.

Parmi les anecdotes, Web Archive / archive.org a eu sa fuite de comptes utilisateurs et a été indisponible sur la fin (ce qui rendait compliqué la récupération d’images perdues ou leur remplacement par un lien valide par exemple). Et, mentionné dans la rétrospective de la seconde quinzaine de septembre 2024, un compte de spammeur de 2015 supprimé… mieux vaut tard que jamais : détecté parce que comme beaucoup de visiteurs, le spammeur ne fait pas la différence entre un lien vers un document et l’ajout d’une image.

Les problématiques restantes

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 du remplacement des composants devenus non-libres (migrer vers valkey plutôt que redis ? Questions à se poser sur l’avenir de nginx ?).

On pourrait aussi ajouter la prise en charge du TLS et d’un certificat X.509 directement dans img plutôt que dans un frontal. Mais ce n’est utile que si on les sépare sur deux serveurs distants, ce qui n’est pas le cas actuellement. Donc même si ça ne paraît pas compliqué à faire, ce n’est pas urgent.

Ensuite une entrée de suivi existe pour séparer le cache des avatars du cache des autres images : les contraintes pour le cache des avatars étant différentes de celui des autres images, le stockage en cache devrait être différent. Cela reste un problème mineur. Le changement doit d’abord être fait côté Ruby on Rails pour définir les avatars avec des clés redis différentes (genre avatars/ au lieu de img/). Ensuite on peut modifier img pour séparer le traitement des requêtes HTTP /img/<adresse_hexa> vers les clés redis img/<adresse> et le cache disque des images par rapport aux requêtes /avatars/<adresse_hexa> vers les clés avatars/<adresse> et le cache des avatars. Il faudra aussi déplacer les avatars stockés dans l’actuel cache des images dans leur propre cache. Et là on devrait pouvoir avoir la même adresse dans les deux caches mais avec un rendu éventuellement différent.

Un autre problème concerne la non-association des contenus ou commentaires avec les images externes qu’ils contiennent, ce qui rend l’administration des anciennes images un peu pénible. Le fait que les contenus et commentaires peuvent être réédités ou simplement prévisualisés (donc que des images peuvent être supprimées et d’autres ajoutées) vient compliquer un peu la tâche. Actuellement un ensemble de scripts permettent d’obtenir ces infos et fournissent un contournement, mais ça reste un peu laborieux.

Un cache rafraîchi périodiquement conserve les images pour éviter de surcharger le site d’origine, pas si le site a changé, déplacé ou perdu l’image. La modification pour servir depuis le cache disque en cas d’échec de récupération couvre le cas de la disparition d’une image avec une erreur sur l’adresse, pas celui où le serveur répond une mauvaise image. Il y a donc une autre entrée de suivi images et disparition du web évoquant l’augmentation des soucis sur les images externes avec un cache rafraîchi, en raison des domaines récupérés par des spammeurs et autres pénibles, ou perdus ou utilisés pour du phishing (imageshack.us, après framapic, pix.toilelibre, etc.). Diverses problématiques sont mentionnées comme la perte d’information et donc la diminution de l’intérêt des contenus anciens, la prime aux pénibles du référencement SEO qui pourrissent le net en récupérant les vieux domaines, la modification possible des images publiées. Pour résoudre cela techniquement, ça nécessite de suivre les images et les domaines perdus, et d’intervenir de façon régulière. Ou bien de ne plus rafraîchir le cache (que cela soit jamais, après la publication ou au bout d’un certain temps après la publication). Pour juste éviter la perte d’info, il est possible de remplacer par une image locale récupérée d’une archive du net type archive.org, avec le côté « pénible à faire » et sans garantie que ça soit toujours possible (merci waybackpy).

Enfin une troisième entrée de suivi suggère l'hébergement des images des dépêches (et éventuellement des journaux), idéalement en permettant d’avoir une version modifiée d’une image en changeant sa taille. On peut citer en vrac comme problématiques la responsabilité légale, l’éventuelle volumétrie, l’impossibilité de corriger une image publiée facilement par la personne qui l’a soumise, la centralisation et la perte de référencement pour des tiers, l’éventuelle rétroactivité et le traitement de l’historique, le fait qu’il faut traiter tous les autres contenus/commentaires pouvant accueillir des images, etc. Autre question, faut-il différencier les images passées en modération a priori de celles en modération a posteriori ?

Conclusion ?

Bref sans surprise, 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).

img apporte les fonctionnalités que l’on attendait de lui même si on pourrait faire 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 redis et du nginx, du hurl et de l’HTTP. Et 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. Reste à savoir si j’ai répondu à l’attente d’un article technique sur le fonctionnement de ce cache, les choix techniques qui ont été faits, les erreurs commises donc à éviter… et la réponse est à trouver dans les commentaires.

Revenons sur les nouveautés de LyX 2.4 à l’occasion de la sortie de la 2.4.2, qui apporte son lot de correctifs.

LyX est un éditeur de documents WYSIWYM (what you see is what you mean) prévu pour l’environnement TeX et disponible sous licence GPL. Contrairement à Word ou LibreOffice, par exemple, l’utilisateur ne voit pas directement à l’écran le même résultat que s’il imprimait le document (WYSIWYG). Ce mécanisme est voulu, car TeX impose de « compiler » les documents avant de les visualiser : LyX permet donc de visualiser la sémantique du document avant d’en générer un PDF.

La version 2.4 est sortie le 1er juin 2024 et apporte un grand lot de nouveautés, après six ans de développement. Cette version est constituée de 8700 commits par 40 personnes et a permis de fermer 800 problèmes connus.

Parmi les changements principaux, LyX utilise désormais UTF-8 en interne pour la représentation des documents, une évolution qui suit de près LaTeX, qui a fait le même mouvement en 2018 (bien après les moteurs modernes comme XeTeX ou LuaTeX).

Au niveau de l’interface graphique, les thèmes sombres fonctionnent bien mieux qu’avant, notamment au niveau de l’éditeur de formules. Pour Windows, le thème Fusion de Qt est nécessaire pour obtenir une interface sombre.

Au niveau des exports vers d’autres formats que des dérivés de TeX, LyX 2.4 génère désormais du XHTML 5 (c’est-à-dire du HTML5 mais lisible comme du XML). La sortie DocBook a été entièrement réécrite, de telle sorte qu’elle s’utilise désormais sur la majorité des types de documents LyX (à l’exception notable des présentations Beamer). Précédemment, seuls des documents suivant un modèle spécifique à DocBook pouvaient être exportés en DocBook, mais pas en LaTeX : maintenant, un même document pourra être exporté en DocBook et LaTeX. Cette sortie DocBook a aussi été l’occasion d’implémenter une sortie en ePub 3 (utilisant DocBook et les outils standard de DocBook pour convertir un document en ePub 3).

Le développement de LyX se poursuit activement, avec la branche 2.5 en préparation parallèlement aux mises à jour de la branche 2.4. Les améliorations et corrections en cours sont détaillées dans le système de suivi du projet, accessible au public.

Il est remarquable de noter que LyX, lancé initialement en 1995, approche bientôt de ses 30 ans d'existence. Cette longévité témoigne de la qualité et de l'utilité durable de ce logiciel. Il n'a jamais cessé d'évoluer pour répondre aux exigences de ses utilisateurs, en particulier dans le domaine de l'édition scientifique et académique.

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [clubic.com] La secrétaire d'État à l'IA et au Numérique est à la dernière place du gouvernement, un nouvel affront à la Tech
• [LeMagIT] Open Source Summit: Proxmox se dévoile aux clients de VMware (€)
• [Le Monde Informatique] Linus Torvalds incite les codeurs à miser sur les projets open source utiles (€)
• [L'Informaticien] Une initiative pour soutenir les meilleures pratiques open source
• [L'usine Nouvelle] Comment l'Inria veut faire avancer l'open source dans l'IA… tout en monétisant ses recherches (€)
• [ZDNET] La documentation sur Linux et les logiciels libres est un véritable capharnaüm: voici la solution
• [Le Monde Informatique] AWS place Opensearch sous les auspices de la Fondation Linux

[clubic.com] La secrétaire d'État à l'IA et au Numérique est à la dernière place du gouvernement, un nouvel affront à la Tech

✍ Alexandre Boero, le dimanche 22 septembre 2024.

Pour la première fois en France, l’intelligence artificielle est représentée au sein du gouvernement, avec le Numérique. Sauf qu’une fois de plus, les disciplines de la Tech n’ont pas droit à leur ministère.

Et aussi:

• [Numerama] Thierry Breton claque la porte de la Commission européenne, et attaque Ursula von der Leyen

[LeMagIT] Open Source Summit: Proxmox se dévoile aux clients de VMware (€)

✍ Yann Serra, le jeudi 19 septembre 2024.

Le petit éditeur autrichien a vu le nombre d’entreprises intéressées par sa solution de virtualisation exploser depuis que Broadcom a changé les conditions tarifaires de VMware, le leader du domaine.

[Le Monde Informatique] Linus Torvalds incite les codeurs à miser sur les projets open source utiles (€)

✍ Sean Michael Kerner, le mercredi 18 septembre 2024.

Lors de l’événement Open Source Summit Europe de la Fondation Linux, le créateur de Linux a fait le point sur les dernières mises à jour de Linux et sur l’open source.

[L'Informaticien] Une initiative pour soutenir les meilleures pratiques open source

Le mercredi 18 septembre 2024.

Baptisée Developer Relations Foundation (DRF), cette initiative, annoncée le lundi 16 septembre lors de l’OSSummit de Vienne, vise à soutenir et à unifier les meilleures pratiques au sein de la communauté des développeurs open source.

[L'usine Nouvelle] Comment l'Inria veut faire avancer l'open source dans l'IA… tout en monétisant ses recherches (€)

✍ Léna Corot, le mardi 17 septembre 2024.

En présentant le 12 septembre le programme de recherche P16 et la start-up Probabl, l’Inria s’attaque à l’intégralité du cycle de la donnée. L’objectif est de développer et maintenir à l’état de l’art des bibliothèques de logiciels open source tout en parvenant à commercialiser ces ressources avec de nouveaux produits et services.

[ZDNET] La documentation sur Linux et les logiciels libres est un véritable capharnaüm: voici la solution

✍ Steven Vaughan-Nichols, le mardi 17 septembre 2024.

Il ne suffit pas de dire à quelqu’un de se débrouiller tout seul lorsque le manuel est obsolète, illisible ou inexistant. Nous devons améliorer la qualité de la documentation du code, et le moyen d’y parvenir est simple.

[Le Monde Informatique] AWS place Opensearch sous les auspices de la Fondation Linux

✍ Jacques Cheminat, le lundi 16 septembre 2024.

Après avoir forké le moteur de recherche et d’analyse d’Elasticsearch, AWS a décidé de transférer ce projet à la Fondation Linux avec la création d’une entité dédiée la Fondation Opensearch.

🎉 Il y a plus de deux décennies, j’ai lancé mon tout premier Linux-Meetup à Montréal en mai 2003. Depuis, chaque premier mardi du mois, nous avons tenu 252 rencontres sans interruption, rassemblant des passionnés du monde Linux.

🚀 Le samedi 21 septembre 2024, nous fêterons 21 ans de partage autour de Linux et des logiciels libres au Québec ! Cet événement coïncide avec la Journée internationale des logiciels libres (SoftwareFreedomDay), offrant une visibilité mondiale inégalée. Ce sera l’occasion de célébrer cette communauté qui s’est agrandie au fil des années et de marquer cette étape importante dans l’histoire du logiciel libre.

📈 Chaque année, notre événement annuel devient de plus en plus grand grâce à l’appui de nos commanditaires. Avec une participation record de 150 passionnés l’an dernier et le soutien de 23 commanditaires visionnaires.

🌐 L’événement se tiendra en présentiel à l’école de technologie supérieure (ÉTS), à l’université et en virtuelle sur BigBlueButton, permettant à la communauté Linux francophone de participer d’où qu’elle soit.

💼 Si votre entreprise utilise Linux ou soutient les logiciels libres, c’est une occasion unique de promouvoir vos solutions et vos services auprès d’une audience ciblée et engagée. Rejoignez-nous comme commanditaire et bénéficiez d’une visibilité accrue au sein de la communauté. Contactez-moi rapidement pour discuter de votre participation !

🚩 Pour les plus aventureux, la cinquième édition de notre chasse au trésor informatique (CTF : CaptureTheFlag) sera de retour avec des défis inédits, conçus par Dominique Derrier et Pascal Gad. Cet événement interactif mettra vos compétences Linux à l’épreuve et promet des moments captivants pour les participants.

🗣️ Au programme : des présentations passionnantes des experts Linux, le CTF et des opportunités d’échanges avec la communauté, et bien plus encore.

🎟️ Ne manquez pas cette opportunité unique de vous inscrire et de découvrir l’agenda complet à https://www.rencontres-linux.quebec/event/21-ans-de-linux-meetup-au-quebec-1/

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [Le Monde Informatique] Nantes Métropole mise sur l'open source pour son archivage numérique
• [ZDNET] La Suisse exige désormais des logiciels open source
• [Next] PPA: le compromis de Mozilla sur la publicité ne plait pas à tout le monde
• [ZDNET] Comment (et pourquoi) l'open source attire les plus grands innovateurs du monde
• [01net.] Peu utilisés, instables… les logiciels made in France de l'État coûtent un pognon de dingue
• [Campus Matin] Vers la fin de l'outil de visioconférence Zoom dans les établissements publics de l'ESR?

[Le Monde Informatique] Nantes Métropole mise sur l'open source pour son archivage numérique

✍ Dominique Filippone, le vendredi 26 juillet 2024.

Externalisation: Regroupant 24 communes dans le département de Loire Atlantique, Nantes Métropole a confié à Atos le déploiement de son système d’archivage électronique reposant sur la solution open source Vitam conçue et développée par l’Etat.

[ZDNET] La Suisse exige désormais des logiciels open source

✍ Steven Vaughan-Nichols, le mercredi 24 juillet 2024.

La Suisse vient de faire un grand pas en avant avec une loi révolutionnaire qui impose l’utilisation de logiciels libres dans le secteur public du pays. Explications.

[Next] PPA: le compromis de Mozilla sur la publicité ne plait pas à tout le monde

✍ Vincent Hermann, le mardi 23 juillet 2024.

Avec Firefox 128, Mozilla a introduit une fonction baptisée PPA, pour Privacy-Preserving Attribution. Mais entre cette arrivée sans crier gare et le fonctionnement – pas toujours bien compris – du mécanisme, les critiques ont fusé.

[ZDNET] Comment (et pourquoi) l'open source attire les plus grands innovateurs du monde

✍ Steven Vaughan-Nichols, le lundi 22 juillet 2024.

Certains des meilleurs profils IT travaillent dans le domaine de l’open source. Qui sont ces personnes? Comment sont-elles arrivées là? Quelle est leur vision de l’avenir de l’open source?

[01net.] Peu utilisés, instables… les logiciels made in France de l'État coûtent un pognon de dingue

✍ Stéphanie Bascou, le dimanche 21 juillet 2024.

La Cour des comptes, qui évalue les actions faites en matière de numérique de l’administration, livre un bilan plus que mitigé de «la suite numérique de l’agent public», un ensemble de services développés en interne par et pour l’administration qui vise à concurrencer Google doc ou Slack.

[Campus Matin] Vers la fin de l'outil de visioconférence Zoom dans les établissements publics de l'ESR?

✍ Isabelle Cormaty, le jeudi 18 juillet 2024.

En mars 2023, le ministère de l’enseignement supérieur a mis à disposition des établissements publics la solution de classe virtuelle BigBlueButton (BBB). Si l’offre a suscité de nombreuses critiques à son démarrage, elle est davantage appréciée aujourd’hui après l’augmentation des tarifs de Zoom.

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.

Sommaire

• Préambule
• Les formats matériels, entre coût et rangement
  • Les rouleaux, volumen ou rotulus
  • Des formats des livres
  • Les formats actuels, livre et papier
• Les formats de texte
  • Le texte brut, .txt
  • Le RTF
  • Le .doc, un format propriétaire incontournable
  • L’ODT : un format ouvert
  • Le format DOCX et son OOXML
• Des langages de balisages
  • TeX le grand ancien
  • Le SGML et ses petits
    • HTML, sans lequel, possiblement, LinuxFr.org ne serait pas
    • XML le futur du HTML
  • Langages de balisage léger
• L’archivage et la conservation des textes
  • EPUB
  • PDF
• Kurinto une histoire de chasses
• Les textes et documents qui ont servi à alimenter cette dépêche
  • Les formats matériels
  • Les formats numériques (texte et archivage)
  • La police
• Postambule

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 16^e 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.

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.¹

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 pages² 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.

Recto : deux séries de pages tête en bas, pages 12, 13, 16 et 9 (1^re série) et 8, 17, 20 et 5 (2^e 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 (1^re série) et 6, 19,18 et 7 (2^e 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.

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 RFC³ 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 commande⁴. 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’imprimante⁵) 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 1^er 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 plusieurs⁶ :

• 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, OpenOffice⁷, 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.⁸

À 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).⁹

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 »¹⁰, 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 »¹¹. 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.

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)

• Alignement, direction, sens du texte et Writer, avril 2024, pour retrouver la chronologie qui sert d’illustration et d’ossature à cette partie. Elle sert de base à un tutoriel qui vous permettra d’en refaire d’autres couplé à celui-ci.
• About US (en) et Membres d’OASIS (en), OASIS Open.
• Le standard ODF 1.3, OASIS, avril 2021. Il est également possible d’acheter la version 1.2 au prix de 215 CHF sur le site de l’ISO.
• OASIS Open Europe Foundation (en).
• Le langage SGML : vue d’ensemble et derniers progrès, George Charlebois, Flash Réseau, numéro 3, décembre 1994.
• Court historique du HTML, mars 2014.
• Spécifications HTML (en), WHATWG, juillet 2024.
• Fiches format BnF, des fiches qui sont vraiment bien faites et elles donnent une indication des volumes des formats dans les collections de la BnF.
• Document de politique de conversation BnF (pdf).
• Histoire de l’ebook #9 - L’EPUB devient le format standard, Marie Lebert, 23 juin 2021.
• PDF. Trois lettres qui continuent de changer le monde, Adobe.
• PDF hybride : LibreOffice, OpenOffice et PDF, JR Boulay, juin 2024.

La police

• Règles et usages de typographie française (pdf), Gérald Purnelle, Université de Liège, mai 2024.

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.

La 11ᵉ édition de Kernel Recipes aura lieu du 23 au 25 septembre 2024, à la Fondation Biermans Lapôtre, à Paris.

Nous entamons la deuxième décennie de la conférence, avec toujours autant de plaisir à organiser et réunir orateurs et participants pour trois jours de convivialité et d’échanges.

Notre parrain cette année est Arnaldo CARVALHO DE MELO (acme), contributeur au noyau. Il nous a accompagné d’une main de chef sur la préparation de l’agenda 2024.

Encore une très belle affiche qui nous l’espérons vous plaira, dans la salle, lors du live stream ou des vidéos en ligne plus tard : Maira CANAL, Himadri SPANDYA, Jose MARCHESI, Anel ORAZGALIYEVA, David VERNET, Steven ROSTEDT, Andrea RIGHI, Greg KH, Neeraj UPADHYAY, Paul MCKENNEY, Andrii NAKRYIKO, Pavel BEGUNKOV, Jens AXBOE, Breno LEITAO, Vlastimil BABKA, Arnaldo CARVALHO DE MELO, Sebastian ANDRZEJ, Derek BARBOSA, Guilherme AMADIO…

Également présents, Frank TIZZONI pour saisir au vol de manière impitoyable les participants et les orateurs et Anisse ASTIER qui proposera à nouveau son excellent live blog.

Enfin un immense merci aux sponsors qui nous supportent à nouveau cette année et rendent possible cette conférence : la fondation eBPF, ARM, AMD, Collabora, Meta, Haproxy, Jumptrading, Criteo engineering, Igalia, Cyberzen

La gestion du son et des images sera proposée par Uweti.

Cette revue de presse sur Internet fait partie du travail de veille mené par l’April dans le cadre de son action de défense et de promotion du logiciel libre. Les positions exposées dans les articles sont celles de leurs auteurs et ne rejoignent pas forcément celles de l’April.

• [ZDNET] Libre et open source express: OpenStreetMap, Panoramax, Signal, Murena, mentorat
• [Siècle Digital] Comment Mistral AI part à la conquête de l'Amérique
• [Les Echos] Comment créer une communauté puissante et développer son business
• [ZDNET] Bureautique et collaboration: la Dinum déroule La Suite Numérique

[ZDNET] Libre et open source express: OpenStreetMap, Panoramax, Signal, Murena, mentorat

✍ Thierry Noisette, le vendredi 31 mai 2024.

Journées OpenStreetMap. La FAQ de Panoramax. Meredith Whittaker (Signal) et la concentration des IA. Gaël Duval et les smartphones Murena. Plaidoyer pour le mentorat des contributeurs occasionnels.

[Siècle Digital] Comment Mistral AI part à la conquête de l'Amérique

✍ Benjamin Terrasson, le jeudi 30 mai 2024.

Mistral AI commence a étoffé ses équipes aux États-Unis pour s’imposer sur place en alternative aux IA des géants du web.

[Les Echos] Comment créer une communauté puissante et développer son business

✍ Noémie Kempf, le mardi 28 mai 2024.

A partir de l’exemple de Linux, Noémie Kempf, autrice du «Pouvoir des communautés»*, explique comment l’approche communautaire peut favoriser le développement de votre entreprise.

[ZDNET] Bureautique et collaboration: la Dinum déroule La Suite Numérique

✍ Louis Adam, le lundi 27 mai 2024.

Derrière ce terme, la direction interministérielle du numérique regroupe une suite d’outils bureautique et de collaboration à destination des agents publics. Voici ce qu’il contient.

Mozilla, par l’intermédiaire de son Community Manager, vient de lever le voile sur les prochaines fonctionnalités du Navigateur Firefox et des priorités de l’équipe de développement. Les maîtres-mots des améliorations à venir sont la productivité, la personnalisation, la simplicité et la performance. La feuille de route met aussi l’accent sur la compatibilité inter-navigateurs et l’utilisation de l’IA locale pour améliorer l’accessibilité et préserver la confidentialité des utilisateurs.

Rentrons un peu plus dans le détail.

Petit zoom sur les nouvelles fonctionnalités

• Côté productivité, notons du neuf du côté des onglets
  • Le regroupement d’onglets,
  • Les onglets verticaux
  • mais aussi un nouveau système de gestion des profils pour mieux séparer les contextes de navigations (par exemple scolaire, professionnel ou encore personnel) tout en les rendant facilement accessibles.
• Pour la personnalisation, les fonds d’écran personnalisables à l’ouverture d’un nouvel onglet débarquent, comme ce qui se fait à la concurrence. Ceux qui comme moi utilisent des extensions de type Tabliss ne verront pas la différence.
• Des paramètres de confidentialité qui se voudront plus intuitifs afin de mieux comprendre et utiliser les technologies anti-pistage du navigateur.
• Une rationalisation des menus pour réduire l’encombrement visuel et donner la priorité aux principales actions de l’utilisateur.

L’Intelligence Artificielle (IA) est aussi de la partie, mais de manière prudente et mesurée. Dans les tuyaux, l’IA locale sera mise à l’épreuve pour améliorer l’accessibilité (génération de texte alternatif) tout en préservant la confidentialité des utilisateurs (au même titre que la fonctionnalité de traduction de site réalisée localement par exemple).

Sous le capot, l’équipe de développement veut encore accélérer le démarrage et le chargement des pages et économiser la batterie de nos précieux. Ils se targuent d’une amélioration des temps de réponse de 20% sur Speedometer 3. Ils travaillent aussi avec le projet Interop pour améliorer la compatibilité inter-navigateurs et faciliter la vie des développeurs web. C’est dans ce contexte qu’a été ajouté la fonctionnalité pour leur remonter facilement des sites qui dysfonctionnent.

Hic et nunc

Pour les plus impatients d’entre vous, certaines de ces nouvelles fonctionnalités sont déjà en cours de développement et peuvent être accédées via les canaux beta et nightly, en jouant éventuellement avec les entrées du about:config, avec tous les risques d’instabilité et de perte de données que cela comporte, vous êtes prévenus.

Dans cette nouvelle excursion du Transimpressux, nous voyagerons chez les Mayas de l’époque pré-colombienne ainsi que dans la Rome antique. Nous ferons un rapide tour des monastères médiévaux, nous irons rendre une courte visite à Aloys Senefelder à Munich. Nous en profiterons pour aller voir Isaac Newton, Tintin et Astérix et on terminera notre voyage à Kreutzal, en Allemagne. On n’y parlera pas de Rahan, quoique. On aura compris qu’il sera question d’image, d’écriture et de texte.

Le bar du Transimpressux vous propose un vaste échantillon issu du pas si grand livre des recettes de LinuxFr.org. En espérant qu’à la lecture de cette dépêche vous aurez fait un beau voyage.

Sommaire

• Préambule
• Quelques définitions avant de commencer
• L’écriture et l’image, des concepts différents vraiment ?
  • L’exemple des hiéroglyphes mayas
  • Le contre exemple romain
• La séparation du texte et de l’image
  • Les manuscrits médiévaux, une séparation parfois extrême
  • L’imprimerie : des typographies ornementales
  • La bande dessinée : des métiers différents
• Qu’est-ce que le texte ?
• Nouveau Drop Caps : une police de lettrines
• Les textes et documents qui ont servi à alimenter cette dépêche
• Postambule

Préambule

Au départ, j’avais prévu de parler aussi de formats, mais, à l’arrivée, c’est déjà bien long. La question des formats fera donc l’objet d’une autre dépêche de la série.

J’utilise indifféremment les termes de fonte, police, police de caractère ou typographie. Et, comme il sera question de périodes très éloignées dans le temps, celles antérieures à notre ère seront indiquées sous la forme AEC (avant l’ère commune).

Quelques définitions avant de commencer

Il est possible que certaines notions ne vous soient pas claires, ces quelques définitions vous seront peut-être utiles.

• Codex : livre formé de feuilles pliées et assemblées en cahiers, et couvert d'une reliure tel que nous le connaissons.
• Logogramme, logographique : un logogramme est un dessin représentatif d'une idée ou d'une suite de sons, utilisé dans une écriture idéographique.
• Pictogramme, pictographique : un pictogramme est un dessin figuratif ou symbolique utilisé pour communiquer sans langage parlé.
• Idéographique : qui représente directement les idées par des signes propres à les suggérer.
• Phonogramme, phonographique : dans ce contexte, signe graphique susceptible de représenter un son.
• Glyphe : représentation visuelle des caractères.

L’écriture et l’image, des concepts différents vraiment ?

L’écriture n’est pas de l’image, l’image n’est pas de l’écriture. Oui et non.

L’exemple des hiéroglyphes mayas

Le système d’écriture maya n’est pas purement logographique. D’ailleurs est-ce qu’un système d’écriture uniquement logographique ou pictographique existe vraiment ? On a vu précédemment sur LinuxFr.org concernant les systèmes d'écriture que les hiéroglyphes égyptiens et les sinogrammes n’étaient pas composés que de pictogrammes, mais qu’ils allaient de pair avec d’autres signes, notamment phonographiques. Il en va de même avec l’écriture maya qui

est un système graphique normalisé qui, au moyen de quelques centaines de « signes-mots » (ou logogrammes) et environ 150 phonogrammes marquant des syllabes de type Consonne-Voyelle¹.

L’écriture maya est apparue, à notre connaissance vers 400 AEC et a été utilisée jusqu’au XVII^e siècle où l’envahisseur espagnol a tout fait pour l’éradiquer, y compris en brûlant des codex. Entre les Espagnols et le climat chaud et humide de la sphère d’influence maya, on ne connaît plus que trois codex mayas précolombiens² : le codex de Dresde, celui de Paris et celui de Madrid. Un quatrième codex, le codex Grolier, conservé à Mexico est sujet à controverses, sa datation et son authenticité ne sont pas certaines. Mais on retrouve aussi l’écriture maya sur des monuments et du mobilier. On trouve également des graffitis, signe, sans doute, d’un certain niveau d’alphabétisation de la population maya. L’écriture maya devait transcrire plusieurs langues amérindiennes, lesquelles langues ont toujours des locuteurs.

Deux pages du codex de Paris

Pour autant qu’on sache, pour les Mayas, leur écriture tout au moins, l’image était importante. Selon Jean-Michel Hoppan :

Cette écriture est rigoureuse et, tout à la fois, très souple. Elle n’est pas normalisée, au contraire de l’idée qu’on se fait habituellement d’une écriture. Le scribe peut privilégier l’esthétisme au détriment de la compréhension immédiate (en tout cas pour nous). C’est encore plus évident sur les céramiques, où le texte est parfois complètement inintelligible. Le glyphe est là, toujours chargé du pouvoir de l’écrit, mais le contenu de la parole n’est plus. Il devient image. Il y a une grande partie de la céramique où l’on voit de l’écriture, mais qui, de fait, est constituée de pseudoglyphes.³

Les hiéroglyphes mayas n’ont pas de bloc Unicode, même si les chiffres y figurent depuis la version 11.0 (juin 2018). Un billet du blog du consortium (en) du 23 janvier 2020 annonçait l’existence d’une subvention « pour restituer numériquement des écritures historiques et modernes supplémentaires, y compris des hiéroglyphes mayas. ». L’idée étant aussi de faire progresser la recherche de la connaissance de l’écriture et de la culture maya sur les sites de la période 250 – 900, une étape importante pour déterminer les signes à intégrer à Unicode, et d’aboutir à la création de polices OpenType. La dernière version de la norme Unicode, 15.1.0, date du 12 septembre 2023, un peu juste pour incorporer les hiéroglyphes mayas quand on sait que la création d’une police peut prendre de quatorze à seize mois.

Le contre exemple romain

L’alphabet latin puise ses origines dans l’alphabet étrusque, qui, lui-même, provient du système d’écriture grecque et c’est, bien entendu, celui que nous utilisons sur LinuxFr.org (le latin, pas le grec, suivez un peu). C’est celui de l’ASCII. Il figure dans l’Unicode, évidemment, où il dispose de plusieurs blocs. Le bloc latin de base contient en fait tous les caractères et commandes de l’ASCII. Il n’a pas été modifié depuis la version 1.0.0 d’Unicode.

D’après les écrits qui nous sont arrivés, les Romains avaient une vision très « utilitariste » de l’écriture. Pour eux (les écrits qui nous sont parvenus sur le sujet proviennent essentiellement d’hommes) :

l’écriture est essentiellement destinée à (…) représenter [le langage]. De plus, dans sa version alphabétique, qui est à peu près la seule à laquelle pensent les Latins, l’écriture est une notation des sons, les lettres renvoient à des sons élémentaires et l’alphabet correspond terme à terme (en principe) à un inventaire fini de ces sons.⁴

Il s’agissait donc pour les anciens Romains non pas de

faire une science de la langue à travers sa représentation graphique, mais bien une science de l’écrit en tant qu’il renvoie à la langue. (Françoise Desbordes).

Un support du langage bien imparfait d’ailleurs puisqu’il ne rend pas les effets du discours oral. Et ce facteur explique aussi que la graphie ait mis du temps à se normaliser. L’écrit étant l’image de l’oral : la langue pouvait être prononcée par des locuteurs avec des accents différents et s’écrire ainsi en fonction de la prononciation.

Les écrits des Romains étaient variés, indépendamment des discours, naturellement et sous diverses formes : monumentales, tablettes de cire, papyrus, mais aussi graffitis que l’on pouvait retrouver sur les murs des édifices privés. Des graffitis qui étaient destinés à être lus et étaient très liés à l’oral :

les messages interpellant parfois nommément, au vocatif, une personne – homme ou femme. Ainsi s’explique aussi l’abondance des exclamations (feliciter ! salutem !), des salutations (salve vale !) et des vœux (votum aux Lares pour la salus du maître de maison). Leur caractère performatif ne fait pas de doute.⁵

Graffiti de Pompéi vantant les exploits sexuels du miles Floronius (CIL, IV, 8767). Wolff 2012, 19, fig. 7.

La séparation du texte et de l’image

Des compétences, des métiers et des techniques différentes.

Les manuscrits médiévaux, une séparation parfois extrême

Le travail de copie des monastères médiévaux, notamment (la profession se sécularisera à partir du XIII^e siècle), différait en fonction des lieux et des époques. Au début, le, ou les copistes, suivant en cela, semble-t-il, les traditions grecques et romaines, étaient également chargés de l’ornementation. Les copistes, parce que la copie d’un manuscrit pouvait être distribuée en plusieurs cahiers à différents copistes pour accélérer le travail de copie. La ponctuation, quant à elle, était généralement du ressort des correcteurs, quand il y en avait, pas des copistes.

Il arrivait aussi qu’il y ait un copiste pour le texte et un pour les enluminures, surtout pour les manuscrits les plus riches. Dans ce cas, le ou la copiste écrivait la lettre à enluminer et laissait la place nécessaire, à charge pour l’enlumineur ou l’enlumineuse d’orner le parchemin. Les copies n’étant pas du ressort unique des monastères, les enlumineurs et les enlumineuses étaient souvent des peintres.

Et parce que le travail était ainsi le fait de corps de métier différents, il subsiste des manuscrits médiévaux pas finis, avec des « blancs » pour des enluminures qui ne verront jamais le jour.

L’imprimerie : des typographies ornementales

Jusqu’à la fin du XVIII^e siècle, les techniques d’impression ont assez peu évolué. Il y avait des perfectionnements et des améliorations, certes, mais, les techniques restaient grosso modo celles de Gutenberg. Les illustrations étaient gravées à part, puis, après la découverte fortuite de la lithographie par Aloys Senefelder en 1796 dessinées sur la pierre, ce qui permettait aux artistes de travailler directement sur la pierre sans avoir à passer par l’intermédiaire d’un graveur. La lithographie permet en effet de dessiner le motif sur la pierre, à l’origine. Senefelder travaillera aussi sur plaque de zinc. La lithographie repose sur le principe de l’antagonisme de l’eau et de la graisse : les zones à imprimer sont traités à la graisse, les autres sont mouillées. L’encre grasse se dépose ainsi seulement sur les zones grasses.

Si l’impression en noir et blanc pouvait se faire d’une traite, celle en couleurs, selon les exigences et les techniques utilisées, pouvait requérir jusqu’à quatorze opérations différentes, et presque autant de passages couleurs. L’offset actuel, un procédé qui dérive de la lithographie, fonctionne en quadrichromie : cyan, magenta, jaune et noir (CMJN) et autant de passages couleur.

Les ornements plus susceptibles d’être réutilisés : lettrines, culs-de-lampe et autres fleurons, lignes et arabesques faisaient l’objet, quant à eux, de fontes ornementales spécifiques. Il y avait même des graveurs typographes spécialistes de typographie ornementale comme Joseph-Gaspard Gillé (pdf) (1766-1826). Aujourd’hui, ce genre de fonte peut se trouver, dans les blocs Unicode de systèmes d’écriture, notamment, latin. On y retrouve d’ailleurs bon nombre de ces polices ornementales purement figuratives même si leur dessin ne correspond pas à une lettre. Mais elles pourraient aussi bien figurer dans les flèches, les filets, les pavés, le bloc casseau ou encore les deux zones supplémentaires.

Les symboles du zodiaque de la collection de fontes de Gillé. Les symboles du zodiaque figurent dans les points de code Unicode U+2648 à 2653 (avec des dessins moins figuratifs).

Toutes les techniques d’imprimerie continuent à exister, de façon plus ou moins anedoctique. Les deux plus répandues étant l’offset, pour les gros volumes, et l’impression numérique (laser ou jet d’encre). Cette dernière étant la seule à imprimer les couleurs d’une seule traite.

La bande dessinée : des métiers différents

La bande dessinée ce n’est pas un métier mais quatre métiers différents qui peuvent ou non, être assurés par la même personne :

• le scénario,
• le dessin,
• la couleur,
• et le lettrage qui nous intéresse ici.

Le lettrage, dans la bande dessinée ce sont en fait plusieurs types d’écriture :

le paratexte (titres, signatures, numérotation), les interventions du narrateur (récitatifs, didascalies, commentaires), toute la notation des sons (dialogues, onomatopées, bruits) – le lettrage assume ainsi une part très importante du « régime sonore » de la bande dessinée, au point que l’on appelle « muettes » les bandes dessinées qui n’en comportent pas du tout (puisque le lettrage n’est pas indispensable à la réalisation d’une bande dessinée).⁶

Gotlib (les Dingodossiers, la Rubrique à brac, Super Dupont, Gai-Luron) est entré en bande dessinée par la voie du lettrage.

Un extrait des Dingodossiers de Gotlib, scénario de Goscinny. L’image comporte des didascalies à gauche et en haut à droite, une bulle de texte, en-dessous, du texte « sonore. »

D’autres auront leur lettreur attitré, comme Hergé. Arsène Lemey a assuré le lettrage de ses Tintin à partir de la version allemande du Secret de la licorne, le onzième album de la série. La police de caractère créée par Arsène Lemey pour Tintin est l’Arleson, elle sera intégrée à la photocomposeuse de Casterman dans les années 1970. Pour la série Astérix ce sont les lettrages de Michel Janvier, en charge de cette tâche pour un certain nombre d’album depuis 1989, qui ont été numérisés. Trois famille principale de typographies ont ainsi été créées par Le Typophage : Regularus pour les bulles, Boldus pour l’écriture très grasse et Graphix pour les onomatopées et les symboles graphiques.

Avoir sa propre police est actuellement assez facile en passant par des sites comme le Calligraphe qui permettent de générer une typographie à partir de son écriture manuscrite. C’est ce qu’a fait notamment heyheymomo (en) qui offre sa police en téléchargement (en).

Qu’est-ce que le texte ?

Au début de l’informatique, chez IBM l’unité de mesure était le mot (word). La capacité d’une machine s’évaluait donc en nombre de mots. Un mot étant, selon le manuel de l’IBM 605 constitué de « dix chiffres et d’un signe algébrique ». Ainsi l’IBM 605 avait une capacité de 1 000 à 2 000 mots. Le texte n’était pas bien loin.

Mais, qu’est-ce que le texte ? Selon les points de vue, la notion de texte peut être très vaste. En musique par exemple, il est question de sous-texte et ça n’a rien à voir avec les paroles de chanson ou de mélodies ou le livret des opéras. Dans le cadre de cette série qui, globalement, traite de l’informatique dans le contexte historique de l’écriture, j’opte pour une définition restrictive et axée sur l’écriture et la lecture.

Le texte est ainsi de l’écriture qui peut se lire avec les yeux, les oreilles ou les doigts et qui peut aussi être lue par des robots. C’est du texte fait pour être lu pas pour être exécuté dans le cadre d’un logiciel par exemple. Ce qui exclut le code informatique de la définition, même si c’est écrit avec des éditeurs de texte⁷. On doit pouvoir faire des recherches dans le texte, naviguer dedans, en extraire une partie pour la réutiliser ailleurs, etc.

Il s’ensuit qu’une image avec de l’écriture dessus, ce n’est pas du texte. Un fichier PDF, fac-similé d’un livre imprimé n’est pas du texte. Et les versions PDF des livres numérisés que propose la BnF Gallica par exemple ne sont pas du texte. Un formulaire en PDF qui est en fait une image que l’on aura modifiée avec un outil de dessin (ou imprimé et modifié à la main puis numérisé) n’est pas du texte.

En revanche, si, de mon point de vue, la structure d’une base de données n’est pas du texte, son contenu par contre, oui. Ainsi, au hasard, celle de LinuxFr.org, est du texte, la partie publique tout au moins. Et ce n’est pas Claude qui me contredira.

Un genre d’allégorie des tables de la base de données de LinuxFr.org.

Il est d’autant plus important d’insister là-dessus qu’il se trouve encore des personnes qui ne font pas la différence entre les deux. Et ce, tout simplement parce que c’est écrit et qu’elles, elles, peuvent lire ce qui est écrit.

Nouveau Drop Caps : une police de lettrines

Puisque qu’il a été question plus haut de typographies purement décoratives, c’est l’occasion de vous présenter une police qui ne peut servir qu’à des lettrines ou des titres.

Nouveau Drop Caps est une fonte générée par Dieter Steffmann (en) un typographe de formation qui a créé plus de trois-cent-cinquante polices. La plupart sont plutôt plus à des fins décoratives que des polices de texte. Dans l’ensemble, ses polices peuvent être utilisées pour la langue française, elles ont les caractères qu’il faut. La position de Dieter Steffmann sur son travail est la suivante :

je considère les polices de caractères comme un patrimoine culturel, je ne suis pas d’accord avec leur commercialisation. Les polices autrefois fabriquées à partir de caractères métalliques avaient évidemment un prix en fonction de la valeur du métal, et le coût de conception, de découpe et de moulage est convaincant, d’autant plus que l’acheteur devenait également propriétaire des polices achetées !

Le site sur lesquelles il les dépose, 1001 fonts a, d’ailleurs, une licence (en), avec une disposition assez originale. La police

peut être téléchargée et utilisée gratuitement pour un usage personnel et commercial, à condition que son utilisation ne soit pas raciste ou illégale. (…)

Les fontes peuvent être librement copiées et transmises à d'autres personnes pour un usage privé mais pas être vendues ou publiées sans l’autorisation écrite des auteurs et autrices.

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. La plupart sont accessibles en ligne, et, volontairement, il y a un minimum de références à Wikipédia. Il y a, également, le minimum possible de sources en anglais.

L’écriture maya

Jean-Michel Hoppan est l’un des seuls (le seul ?) spécialiste français d’un domaine de recherche (l’écriture maya) qui ne compte qu’une centaine de personnes dans le monde.

• L’écriture maya, Jean-Michel Hoppan, INALCO (2014, 2015 ?).
• Les glyphes mayas et leur déchiffrement, Jean-Michel Hoppan, 2009.
• L’écriture figurative des Mayas Jean-Michel Hoppan, 2008.

La vision romaine de l’écriture

• Idées romaines sur l’écriture, Françoise Desbordes, 1990, EPUB : ISBN 9782402324168, PDF : ISBN 9782402657495, marquage filigrane. La maison d’édition FeniXX qui édite ce livre est spécialisée dans la réédition des livres indisponibles du XX^e siècle.
• L’écriture en liberté : les graffitis dans la culture romaine, Michelle Corbier, extrait de Langages et communication : écrits, images, sons, Corbier Mireille et Sauron Gilles (dir.), éd. électronique, Paris, Éd. du Comité des travaux historiques et scientifiques (Actes des congrès nationaux des sociétés historiques et scientifiques), 2017.

Les manuscrits médiévaux

On peut se procurer ces livres au format PDF (fac-similé), en texte brut (je travaille sur une version que je compte mettre en ligne pour chacun de ces livres), les emprunter en version EPUB à la BnF si l'on a un compte, ou acheter l’EPUB. À noter que, selon les librairies, le fichier EPUB a ou non une protection numérique : ainsi, Le Furet du Nord indique qu’ils n’en ont pas, Cultura annonce une DRM LCP, et la FNAC une DRM Adobe.

• Les manuscrits et les miniatures, Auguste Molinier, Librairie Hachette, 1892.
• Histoire de l’imprimerie et des arts et professions qui se rattachent à la typographie…, Paul Lacroix, Édouard Fournier, Ferdinand Seré, Séré, 1852.

Bonus ! Si vous voulez vous rincer l’œil, l’IRTH (Institut de recherche et d’histoire des textes) a dressé une liste de sites pour accéder au manuscrit médiéval numérisé.

L’imprimerie

• Les techniques d’illustration du livre imprimé, BnF Gallica.
• Imprimer et illustrer en couleur, album de la BnF.
• Impression offset. Qu’est-ce que c’est et comment ça marche ?, Richard H., 24 mars 2022.
• L’Imprimerie, Charles-Lucien Huard, 1892 à télécharger en versions EPUB, PDF et PDF hybride, ou récupérer en image ou en texte brut sur gallica.bnf.fr.
• Notice pour le concours des progrès de l’industrie française en 1819, Joseph-Gaspard Gillé, à télécharger en versions EPUB, PDF et PDF hybride. Le texte de ces versions est précédé d’une présentation avec un mini-glossaire, des notices sur les imprimeurs et inventeurs cités dans l’ouvrage et une biographie de l’auteur. On peut aussi le récupérer en image ou en texte brut sur gallica.bnf.fr.

La bande dessinée

• Lettrage, Laurent Gerbier, Cité internationale de la bande dessinée et de l’image, septembre 2017.

Postambule

La question des formats sera abordée dans le prochain chapitre qui est déjà bien avancé. Et ce n’est pas plus mal, finalement.

Dans le cadre de cette série, il va me falloir traiter aussi de la question des codes (sur laquelle j’ai quelques lacunes, vos suggestions sont bienvenues). Unicode, bien que déjà pas mal abordé, mérite un chapitre à lui tout seul : histoire, composition du consortium, comment on ajoute un système d’écriture à Unicode, et quelques paragraphes sur le code lui-même (et là…). Je pense que je pourrais peut-être caser la norme ISO des écritures dans ce chapitre. Si j’ai parlé de conservation, il va falloir parler de l’archivage : protocoles, accès, ce qui me permettra d’évoquer aussi de la science ouverte, je pense.

Déversons un peu ici la veille du moment pour libérer des onglets ailleurs et partager des liens mais aussi des sources : il s’agit bien évidemment de liens en rapport avec les thématiques du site (en l’occurrence dans cette fournée on trouvera logiciel libre, opendata, développement et vie privée par exemple), et ils sont plutôt variés ; les sources sont des sites web, des lettres d’actus et des réseaux sociaux (dans le cas présent, tous arrivés jusqu’à moi via des flux RSS/Atom), et c’est aussi une manière de les partager et de vous inviter à les suivre aussi. Dans la suite de la dépêche, on parlera donc en vrac UUID, FSF, opendata, JO, linux, grafana, RoR, Docker et bien d’autres choses encore.

• un problème sur reCaptcha sous Firefox oblige Google à revenir en arrière : Google rolls back reCaptcha update to fix Firefox issues (via badcyber.com)
• une comparaison avec l'ActivityPub du Fediverse, l’AT Protocol de BlueSky et Nostr : ActivityPub/Nostr/AT-BlueSky Compared via Ollivier Robert)
• le trafic DNS fuite du tunnel VPN sur Android : DNS traffic can leak outside the VPN tunnel on Android (via badcyber.com)
• « recalculer le Common Vulnerability Scoring System (CVSS) d’une vulnérabilité », c’est compliqué selon L’avenir du futur / Vulnérabilités cherchent analystes : « Cette histoire de l’arbitrage et de la maintenabilité des efforts d’analyse et de qualification exclue de facto toute approche open source qui se grefferait dessus ou voudrait remplacer la National Vulnerability Database (NVD). »
• si seulement je connaissais un projet qui fait du RoR : Docker without Dockerfile: Build a Ruby on Rails application image in 5 minutes with Cloud Native Buildpacks (CNB) (source ?)
• suivez Bearstech si vous voulez (re)découvrir des projets libres et parce que ces ours sont sympas et ont des goûts variés : supervision avec Grafana & k6 (source) ou Grafana Incident (source), IBM qui place son LLM Granite sous licence Apache (source), noyau Linux 6.9 (source), Python 3.13 (source), Yazi : un gestionnaire de fichiers terminal Open Source (source), frontend-stuff pour les gens qui font du front (source) ou Best-websites-a-programmer-should-visit pour tout le développement (source), manipuler du PDF avec Stirling PDF (source), Rage pour du chiffrement de fichiers (source), etc., etc. On pourrait produire des petites brèves uniquement à partir de leur flux :) (mais ne jouez pas aux dés avec ces plantigrades)
• « Lors du vote de la loi JO, l’exécutif a promis de tirer le bilan de l’expérimentation de vidéosurveillance algorithmique avant de la généraliser. Las, une proposition de loi sur la sécurité dans les transports suggère déjà de la prolonger jusqu’en 2027. » La Quadrature via Olivier Tesquet
• open data et CartoDesJO.fr ce qui nous (en France) attend pour les JO, merci Tangui
• le mignon petit train de l’historique de la FSF (source)
• RFC 9562: Universally Unique IDentifiers (UUIDs) source (ou le flux RSS du site), parce que uui en informatique on a souvent besoin d’ID.

Comme beaucoup de domaines scientifiques, la documentation de la diversité linguistique entretient une relation forte avec les mondes du Libre. Dans cette dépêche, je vous propose de découvrir ce domaine à travers la présentation de plusieurs logiciels et ressources libres ou en accès ouvert. La documentation des langues étant un thème peu courant sur LinuxFr.org, on commencera par une présentation de cette problématique. Nous continuerons par une description des deux ressources principales existantes pour cataloguer et se repérer au sein de cette diversité linguistique. Je parlerai ensuite d’ELAN et de FLEX, deux logiciels utilisés pour annoter des enregistrements audio-visuels, une étape clef dans l’analyse linguistique, et qui permet le partage et la réutilisation de ces enregistrements. Enfin, après un court passage sur la question de l’archivage, je présenterai deux compilations de corpus de documentation en accès libre, une pratique récente qui permet de nouveaux questionnements quantitatifs sur les langues orales peu documentées, et qui contribue également à la transparence et la traçabilité des analyses linguistiques.

Sommaire

• L’étude des langues à travers le monde
• Quelques concepts et termes liés à la documentation des langues
• Les catalogues et base de données pour l’identification des langues
  • • L’Ethnologue et l’ISO 639 : une norme gérée par le Summer Institute of Linguistics (SIL)
    • Glottocode : par le Max Planck Institute for Evolutionary Anthropology.
    • Les autres
• Documenter les langues
  • ELAN : des schémas d’annotation flexibles
  • FLEX : gérer un projet de documentation
  • Et il y en a bien d’autres encore
• L’archivage et la compilation de corpus
  • DoReCo
  • Multi-CAST
• Conclusion

L’étude des langues à travers le monde

Actuellement, environ 7000 langues ont été recensées à travers le monde. Ce chiffre ne peut être qu’une approximation car, il n’y a pas de consensus sur la définition de ce qu’est une langue. Une difficulté par exemple est de définir à quel moment une langue est distincte d’une autre. Lorsqu’il y a variation, mais intercompréhension, de nombreux linguistes s’accordent à dire qu’il s’agit alors de dialectes d’une même langue, et donc, lorsqu’il n’y a pas intercompréhension, alors il s’agit différentes langues. Cette perspective considère que tout le monde parle un dialecte (que ce soit celui de référence, ou un plus régional comme celui de Paris, de Marseille, du Québec), la langue n’étant qu’une abstraction permettant de regrouper les diverses pratiques langagières. En ce qui concerne l’intercompréhension, ce critère n’est malheureusement pas absolu car elle peut varier selon les personnes et leur parcours personnel. Et lorsqu’on considère l’évolution d’une langue à travers le temps, sa diachronie, définir ce qu’est une même langue à travers ses évolutions temporelles se complexifie d’autant plus.

Si certaines langues ont émergé récemment, on pense assez souvent aux langues dites créoles (le Bichelamar, les créoles malais, à Madagascar ou au Cap Vert), ou également lorsque certains dialectes se distinguent suffisamment pour ne plus être intercompréhensibles, la tendance actuelle est surtout à la disparition massive des langues. Cette disparition est souvent rapportée à travers la mort des derniers locuteurs et locutrices, on peut aussi considérer qu’une langue meurt lorsqu’elle n’est plus parlée d’une part, et qu’elle disparait si elle n’est pas documentée. Si certains aujourd’hui se questionnent sur la corrélation entre la diversité culturelle et la diversité écologique, il est évident que la disparition des langues correspond également à des inégalités et des tensions socio-politiques.

Bref, la documentation des langues, c’est un sujet actuel, et d’un point de vue scientifique, la perte de cette diversité aura de tristes conséquences sur la connaissance des langues et de l’univers des possibles languagiers, encore souvent sous-estimé :

• l’article The myth of language universals : Language diversity and its importance for cognitive science d’Evans donne un bel aperçu du débat qui existe entre les linguistes fonctionnalistes, notamment les approches générativistes telles que proposées par Noam Chomsky. Pourtant, régulièrement à travers la documentation des langues, des catégories cognitives jusque-là non-soupçonnés, voire rejetées car non-observées, sont identifiés. Nous nous sommes rendu compte récemment qu’un quart des langues grammaticalisaient l’emploi d’évidentiels, ces morphèmes qui indiquent la source d’une information. Au niveau de l’odorat, des neurologistes pensaient que si nous n’avions pas de termes abstraits pour catégoriser les odeurs, c’était lié au fait que notre cerveau ne le permettait pas. La description des termes liés à l’odorat en Jahai (par ici si vous souhaitez écouter du Jahai), qui possède donc des termes spécifiques pour catégoriser les odeurs, a montré le contraire.
• accéder à des facettes non-matérielles de la préhistoire, non-accessibles à travers l’archéologie. La documentation des langues nous permet d’accéder, dans une certaine mesure, aux termes et aux concepts utilisés durant les différentes préhistoires à travers la comparaison des langues et de leurs structures. Les travaux sont nombreux et anciens en ce qui concerne les langues européennes, mais les recherches en linguistique historique (ou comparée) portent également sur toutes les langues connues à travers le monde. Les chercheurs et chercheuses de ce domaine collaborent assez régulièrement avec les archéologues pour retracer les mouvements de population.
• mettre au point des systèmes d’écriture pour les langues orales, ou simplement des traitements de texte adapté aux écritures existantes. Parfois, certaines personnes savent écrire dans la ou les langues officielles du pays, mais ne connaissent pas d’écriture pour une de leurs langues régionales. C’est ainsi souvent le cas pour les personnes au Vanuatu. Le pays reconnait même le droit d’enseigner les langues locales à l’école, mais il n’existe que très rarement des ressources (que ce soit les personnes ou les manuels) pour cela. Parfois, les gens ne connaissent tout simplement pas de système d’écriture.

Quelques concepts et termes liés à la documentation des langues

Comme tout domaine de recherche, la terminologie et les concepts linguistiques évoluent au gré des discussions et peut se distinguer de l’usage attendu des termes. Une étape importante dans la documentation d’une langue est la production d’une grammaire décrivant les structures linguistiques de cette langue. De nombreux linguistes estiment alors qu’on peut dire que cette langue est décrite. Il ne faut pas se tromper cependant, aucun linguiste ne considère qu’une langue est alors complètement décrite. Une grammaire ne contient que quelques aspects estimés actuellement essentielles par les linguistes de terrain. Ces points sont, le plus souvent, une description du système phonologique d’une langue (c’est-à-dire comment les sons d’une langue sont organisés les uns vis-à-vis des autres), des morphèmes et des processus morphologiques associés (la conjugaison, l’expression de la possession, les déclinaisons, les genres, les classifications, etc.) d’une langue et souvent un début de description des processus syntaxiques. Il existe de nombreuses approches pour décrire les faits linguistiques, et la description d’une langue se fait souvent en dialogue avec les pratiques et terminologies qui ont été employées dans l'aire linguistique concernée.

Depuis l’article Documentary and descriptive linguistics de Nicholaus Himmelman, qui a promu la distinction entre la documentation linguistique et la description linguistique, on accorde beaucoup plus d’importance à la production d’un corpus d’enregistrements annotés. On dit alors d’une langue qu’elle est documentée si des enregistrements annotés, de préférences audio-visuels, de cette langue existe. Enfin, il existe la problématique de l’outillage d’une langue, c’est-à-dire si ses locuteurs et locutrices ont accès ou non aux outils informatisés, du traitement texte aux dictionnaires informatisés en passant par la reconnaissance vocale, la transcription automatique, voire aujourd’hui aux modèles de langues et autres ressources nécessitant des corpus beaucoup plus grands.

Les catalogues et base de données pour l’identification des langues

Une problématique récurrente dans le domaine des langues est de clairement identifier la langue sur laquelle on travaille. Cependant, identifier une langue, ce qui relève ou non de cette langue, où elle est parlée, est l’enjeu de nombreux débats, souvent politique, et n’est pas une tâche simple. Quoi qu’il en soit, il existe des ressources, bases de données, qui proposent d’associer à des noms de langues, endonymes ou exonymes, des codes pour rendre leur identification univoque.

L’Ethnologue et l’ISO 639 : une norme gérée par le Summer Institute of Linguistics (SIL)

Ethnologue, Languages of the World, ou plus simplement l’Ethnologue, est une base de données développée et maintenu par l’organisme évangélique SIL, Summer Institute of Linguistic depuis 1951. Elle vise à recenser toutes les langues du monde. L’ISO 639 est une norme issue de ce catalogue, également maintenue par le SIL. Cet organisme est très actif au niveau de la documentation des langues et de la création d’écritures, car un de ses objectifs est de traduire la Bible dans toutes les langues du monde. Historiquement, l’Ethnologue est un des premiers catalogues dont l’objet a été de recenser les langues. Si cette norme semble le plus souvent suffisamment exhaustive pour les besoins liés à l’informatique, après tout, les internautes consultent Internet en très peu de langue, d’un point de vue linguistique, il possède de nombreuses lacunes.

Un premier souci est la nécessité d’avoir une granularité plus importante que simplement la langue. Les linguistes travaillent sur des dialectes et des variétés, sur des familles de langues, et parfois ont travaillé sur des distinctions qui n’ont parfois plus cours. Afin de pouvoir associer ces ressources à des langues, ou des entités linguistiques particulières, l’approche du SIL ne suffit pas.

Enfin, la gestion du catalogue par un organisme religieux, donc avec parfois d’autres enjeux qu’uniquement scientifiques, le fait qu’il s’agisse d’une norme, donc la nécessité de collaborer avec l’ISO, et le fait que seule une partie du catalogue est accessible (il faut un abonnement pour accéder à la totalité de la ressource) rend la ressource moins pertinente pour de nombreux linguistes. Ces limites ont poussé des linguistes à proposer une ressource alternative.

Glottocode : par le Max Planck Institute for Evolutionary Anthropology.

Le projet Glottolog, initialement développé par Sebastian Nordhoff et Harald Hammarström, catalogue non seulement les langues du monde actuelles et passés, les familles de langues et leurs différentes branches, mais également « les restes » des hypothèses de langues ou de regroupements historiques. Cette granularité permet de retrouver les documents associés à chacun de ces objets. Si le catalogue est dédié aux langues moins connues, les langues les plus centrales sont elles aussi répertoriées. Il s’agit actuellement du catalogue mis en avant par les linguistes documentant les langues à travers le monde. L’application Glottolog est disponible via la licence MIT.

Si aux premiers abords, la liste des langues du Glottolog ne se distingue pas franchement de celle de l’ISO 639, c’est parce qu’il faut regarder plus en détail pour comprendre les différences essentielles entre les deux ressources. Notons tout de même la colonne « Child dialects » : « Dialectes enfants », et les champs vides au niveau des colonnes Top-level-family et pour la langue Abai Tubu-Abai Sembuak dans la colonne « ISO-639-3 ». La colonne « Child dialects » représente une information qui n’est pas documenté dans l’ISO 639, ce n’est pas son objet après tout, mais qui est intéressant pour les linguistes travaillant sur cette langue, indiquant qu’un minimum de données sociolinguistiques sont disponibles. Les champs vides dans la colonne « Top-level family » sont dus au fait que ces langues sont des isolats, c’est-à-dire que la linguistique comparée ne trouve pas de correspondances significatives entre cette langue et d’autres langues qui permettraient de les regrouper en une famille. Enfin, le vide dans la colonne ISO-963-3 révèle que la langue Abai Tubu-Abai Sembuak ne possède pas d’entrée dédiée dans la norme.

Ainsi, lorsque l’on consulte une langue en particulière, ici le Nisvai, on voit apparaitre tous les embranchements existants associés à cette langue :

Cette vue de l’arborescence associée à une langue particulière révèle tous les embranchements auxquels peut⁻être associée une langue. Et à chacun de ces embranchements, si des ressources linguistiques ont été identifiées par les mainteneurs du Glottolog, celles peuvent être proposées. Cette fonction permet aux linguistes de trouver des ressources sur les langues proches, non pas géographiquement (même si en pratique c’est le plus souvent le cas), mais d’un point de vue généalogique.

Les autres

Il existe d’autres initiatives pour cataloguer les langues du monde, que ce soit la liste proposée par Wikipedia, la liste de la CIA ou encore The Linguasphere Register, mais ces initiatives ne sont pas aussi pertinentes du point de vue de la documentation des langues.

Documenter les langues

ELAN : des schémas d’annotation flexibles

ELAN est un des logiciels libres (GPL3) les plus utilisés par les linguistes pour annoter des enregistrements audio et vidéo. Il permet d’élaborer des structures d’annotation complexes permettant ainsi de rendre compte des analyses que les linguistes souhaitent associer à un enregistrement. Ces couches d’annotation sont reliées les unes aux autres par des relations logiques, avec le plus souvent une couche de référence indexée temporellement à l’enregistrement. Les annotations les plus courantes sont une transcription, une traduction et une annotation morphologique. Mais des nombreuses autres analyses peuvent être incluses, que ce soit les parties du discours, les références et anaphores, l'animéité, mais aussi les gestes, la structuration du discours, les signes pour les sourds et malentendants.

Dans cette capture d’écran issu d’un texte de DoReCo retravaillé par l’auteur, on aperçoit un extrait de quelques secondes d’une narration nisvaie. Il s’agit d’un des modes de visualisation des annotations proposées par ELAN pour représenter les différentes couches d’annotation. Certaines de ces annotations ont été réalisées à la main par l’auteur, d’autres ont été retravaillées par les algorithmes mis en place par DoReCo, puis manuellement corrigés. Enfin, il y a également des couches d’annotation de la prosodie par le biais de SLAM+.

FLEX : gérer un projet de documentation

FLEX est un logiciel développé par le SIL et dont le code source est régie par la licence LGPL 2.1. Il est conçu davantage pour coordonner l’ensemble d’une documentation linguistique, de la gestion des textes à l’élaboration d’un dictionnaire, en passant par les analyses linguistiques. En revanche, il ne gère pas réellement l’annotation d’enregistrements. De nombreux linguistes l’utilisent en complément d’ELAN.

Si le logiciel est prometteur sur le papier, à chaque fois que je l’ai essayé, j’ai été rebuté par son côté usine à gaz, et surtout ses nombreux plantages notamment lorsqu’on essaie de gérer des fichiers multimédia avec. Et il en est de même pour les autres logiciels développé par le SIL, tel que SayMore pour gérer les métadonnées des enregistrements, WeSay pour faire des dictionnaires en collaboration avec les locuteurs et locutrices, à chaque fois que je les ai essayés, enthousiasmé par leurs fonctionnalités, j’ai été déçu par le fait qu’ils ne fonctionnaient pas correctement sur mon ordinateur.

Cette capture d’écran illustre un des modes de saisie de FLEX, ici la vue tabulaire du lexique, qui permet de rentrer et gérer les définitions des lexèmes (les entrées du dictionnaire) de manière assez rapide. On aperçoit dans la partie en haut à gauche les autres modes d’édition du lexique, et en dessous les autres catégories liées à la gestion d’un projet de documentation : Texts & Words, Grammar, Notebook et Lists. C’est à travers la catégorie Texts & Words que l’on peut par exemple importer des textes transcrits, voire des fichiers ELAN pour peupler la base de données lexicales. Grammar permet de décrire les paradigmes grammaticaux, FLEX propose d’ailleurs quelques algorithmes qui aident à la construction des paradigmes grammaticaux. Notebook et Lists servent à la gestion du projet, le premier pour prendre des notes diverses, et le second pour créer des listes, en particulier des tâches encore à réaliser.

Et il y en a bien d’autres encore

Il existe de nombreux autres logiciels similaires, tels qu’EXmaralda pour l’annotation des enregistrements (surtout utilisé en Allemagne à ma connaissance), Sonal (non libre, et dont le développement semble arrêté) qui est utilisé par les sociologues et les anthropologues pour une annotation thématique de leurs entretiens, Anvil, qui semble intéressant mais que je n’ai jamais réellement vu utilisé, ou enfin le vieux Transcriber qui lui était encore employé par certains projets il y a quelques années. Rentrer dans le détail de tous ces logiciels dépasserait le cadre d’une dépêche comme celle-ci, mais énumérer la diversité logicielle montre qu’il s’agit d’un secteur un minimum dynamique, d’ailleurs la question de la transcription et de l’annotation des enregistrements ne se limite pas du tout qu’au domaine de la documentation des langues du monde.

L’archivage et la compilation de corpus

Afin de conserver et partager les corpus et donnée enregistrées par les linguistes, chercheurs voire simplement les personnes ayant documenté une langue, il existe des archives, le plus souvent en ligne. Il y a en France par exemple Pangloss, géré par le LACITO, dédié aux langues orales, ou ORTOLANG, plus générique, pour les corpus de langue. En Océanie, il y a Paradisec. Il y a aussi ELAR, autrefois à Londres, et qui a déménagé récemment à Berlin récemment.

Ces archives proposent diverses interfaces pour déposer, gérer et parfois même consulter les enregistrements et les annotations réalisés par les linguistes et leurs collaborateurs·e·s. À noter que pour ces archives, Ortolang décrit son architecture logicielle qui repose sur des briques ouvertes, en revanche concernant Paradisec et Pangloss, bien que leur statuts soient sûrement similaires du fait de la démarche générale de ses ingénieurs, je n’ai pas trouvé de liens vers les logiciels employés. Quant à ELAR, le logiciel utilisé est Preservica, une solution propriétaire qui, quand on a le malheur de devoir l’utiliser, fonctionne bien lentement.

La compilation de corpus, si elle se rapproche de l’archivage en ce qu’il s’agit également de recueillir, conserver et publier les corpus des linguistes, correspond également à une édition particulière de ces corpus. La compilation de corpus est réalisé à travers la mise en place de processus de qualité, d’annotations et de conventions particulières. Les deux compilations de corpus présentées ici sont des compilations de corpus de documentation de langues orales. Les enregistrements ont été systématiquement annotés en utilisant une convention nommée les gloses interlinaires (le nom fait en fait référence à la pratique ancienne d’insérer des explications entre les lignes d’un texte. En pratique aujourd’hui, ce n’est plus vraiment ce que font les linguistes, puisque le travail est informatisé et les annotations ne sont plus entre les lignes, mais, le terme a cependant été conservé).

DoReCo

DoReCo est une compilation de 52 corpus en accès ouvert (NdR : auquelle l’auteur a contribué). La compilation a nécessité la mise en place de processus de qualité afin d’assurer la cohérence de l’ensemble et de fournir un certain nombre de garanties quant aux qualités du corpus.

Une première qualité, et l’une des originalités de DoReCo, est de proposer un alignement temporel est très fin. La durée de chaque phonème, de chaque morphèmes, de chaque mot (ici suivant la définition de la personne à l’origine du corpus, car la définition d’un mot n’a rien d’une évidence) et enfin de chaque groupe de souffle est fournie. Une deuxième qualité a été de s’assurer que pour l’ensemble des retranscriptions, chacun des termes et des morphèmes possède une glose, c’est-à-dire qu’ils possèdent une explication linguistique.

La compilation totalise une centaine d’heures d’enregistrements audio, en grande majorité des narrations monologiques. À noter que les corpus de la compilation sont accès ouvert, via une licence Creative Commons, mais que les droits d’utilisation varient d’un corpus à l’autre. Les données sont accessibles aux formats d’ELAN : .eaf, de Praat : . TextGrid, TEI.xml, et.csv.

Multi-CAST

Multi-CAST est également une compilation de 18 corpus de documentation de langues différentes. Les textes annotés via le logiciel ELAN. Contrairement à DoReCo, l’alignement temporel des annotations n’est pas réalisé de manière précise, mais manuellement, par les personnes à l’origine du corpus, à l’échelle de l’énoncé. Les textes sont également en grande majorité des narrations monologiques. L’originalité de cette compilation de corpus vient du fait que les textes contiennent trois couches d’annotation particulières : GRAID, Grammatical Relations and Animacy in Discourse, (voir), puis RefIND et ISNRef (Referent Indexing in Natural Language Discourse, voir Schiborr et al. 2018).

Cette compilation de corpus est aussi disponible dans plusieurs formats. XML évidemment, puisque c’est le format natif d’ELAN, mais aussi TSV et il existe également un paquet pour R. Tout cela est disponible via la licence CC-BY 4.0.

Conclusion

J’espère que vous avez apprécié cette introduction à la documentation des langues à travers les logiciels libres. L’idée est surtout d’attiser la curiosité, car il reste évidemment encore de nombreux aspects ou points à discuter et à approfondir. La prochaine fois que j’aborderai le thème de la documentation linguistique ici, j’espère que ça sera pour présenter mon application basée sur Django pour faire de la lexicographie.

Il y a également un autre sujet sur lequel j’aimerais bien échanger ici prochainement : la question des licences des données collectés et la négociation lorsque l’on travaille avec des personnes à tradition orale. Si ouvrir l’accès aux données de recherche et aux corpus peut sembler être une évidence pour certains, il ne faut pas oublier que souvent, les chercheurs et chercheuses de terrain collectent des informations personnelles, que la connaissance n’est pas forcément considérée comme un bien public et les enregistrements, notamment les narrations, qui ne sont pas forcément perçues comme des fictions, sont souvent couverts par des droits locaux. Enfin, ouvrir ses données de recherche, si c’est permettre à d’autres de réutiliser ses données, requiert beaucoup de travail de la part des linguistes, c’est une tâche longue, ingrate et surtout peu valorisée. Alors qu’il est de plus en plus précaire d’être chercheur en sciences humaines, il est aussi difficile de demander à ces chercheurs et chercheuses de consacrer une grande partie de leur temps à des tâches qui ne leur permettront pas de se constituer un CV, nécessaire si l’on souhaite avoir un poste stable (c’est-à-dire plus de deux ans).

Label sans IA : ce texte a été rédigé sans aucun aide de la part d’une LLM.

Proxmox Server Solutions GmbH a publié la version 8.2 de sa plate-forme de virtualisation libre Proxmox Virtual Environment (VE).
La solution Proxmox VE est sous licence GNU Affero GPLv3. Proxmox Server Solutions propose un support d’entreprise à partir de 110 € par an et par processeur.

Principales nouveautés de la version 8.2

• La plate-forme Proxmox VE 8.2 est basée sur Debian 12.5 (“Bookworm”), et un noyau Linux 6.8. Les developpeurs ont mis à jour QEMU 8.1, LXC 6.0, Ceph 18.2, et ZFS 2.2.
• Assistant d’import pour les machines virtuelles VMware ESXi : Il facilite aux utilisateurs la possibilité d’importer des machines virtuelles directement à partir d’autres hyperviseurs. Actuellement, il permet d’importer des VM basées sur VMware (ESXi et vCenter). Vous pouvez l’utiliser pour importer la VM entière, avec la plupart des paramètres de configuration d’origine mappés sur le modèle de configuration de Proxmox VE.
• Installation automatisée : un nouvel outil « proxmox-auto-install-assistant » automatise entièrement le processus d’installation sur le métal nu. Le déploiement rapide des hôtes Proxmox VE peut être réalisé grâce à une installation automatisée, éliminant le besoin d’un accès manuel au système. Pour utiliser cette approche, un fichier de réponses contenant les paramètres de configuration requis pour le processus d’installation doit être préparé. Ce fichier peut être facilement inclus dans l’ISO, stocké sur un disque supplémentaire comme une clé USB ou transmis via le réseau.
• Backup fleecing : Lors du processus de sauvegarde d’une machine virtuelle (VM) en cours d’exécution, il est important de prendre en compte l’impact négatif potentiel d’une cible de sauvegarde lente sur les performances des E/S invitées. Pour atténuer cet impact, l’utilisation de toison peut s’avérer très positive. Le «fleecing» implique la mise en cache de blocs de données dans une image de «fleecing» au lieu de les envoyer directement à la cible de sauvegarde. Cette technique est particulièrement utile lors de la sauvegarde d’invités gourmands en E/S sur un serveur de sauvegarde Proxmox distant ou tout autre stockage de sauvegarde avec une connexion réseau lente.
• Modernisation du pare-feu avec nftables (aperçu technologique) : Proxmox VE propose désormais une nouvelle implémentation de pare-feu qui remplace iptables par nftables. La nouvelle implémentation est développée dans le langage de programmation Rust. Bien que la nouvelle implémentation soit presque identique en termes de fonctionnalités, il est important de noter que le pare-feu nftables doit être activé manuellement et reste en mode aperçu, permettant à la communauté de fournir de précieux commentaires.