Le « bon outil » – à propos de LaTeX et Paged.js

Une expérience récente m’a fait réaliser à quel point le choix d’un outil d’édition pouvait être orienté par le document sur lequel on travaille : sa longueur ; la diversité de son contenu ; la complexité du travail à effectuer pour le mettre en forme.

Je prends l’exemple de ma thèse. C’est un long document – environ 280 pages. Le contenu est relativement homogène, avec une liste finalement assez réduite d’objets : des titres, des paragraphes, des citations, quelques images…C’est ce qui explique que la syntaxe Pandoc Markdown réponde à mes besoins.
En revanche, il y a quelques aspects difficiles à réaliser, comme l’index, ainsi que le placement des notes dans la marge.

LaTeX est assez bien adapté à cette configuration. Pour replacer les choses en quelques mots, LaTeX est une interface pour TeX, un système de composition typographique puissant, capable de répondre à des exigences élevées en matière de qualité, mais qui est assez difficile à maîtriser ; LaTeX rend ce système plus accessible via des commandes simplifiées, qu’on peut aller piocher dans un vaste catalogue de modules (les paquets) développés par les autres utilisateursPour en savoir plus, on peut lire la page LaTeX dans la série « Fabriques de publication » d’Antoine.
. L’inconvénient d’un tel système, c’est le risque d’incompatibilité entre les modules. Mais quand on a peu de problèmes à régler sur un document, on n’a pas besoin de beaucoup de modules, et ce risque est alors réduit. Par ailleurs, LaTeX est réputé pour être un peu lent. Mais cela ne me semble pas trop gênant pour une thèse : on sait que ce sera de toute façon un long document complexe, et tant qu’on n’est pas dans les corrections finales, on peut travailler chapitre par chapitre pour alléger le processus.

Je prends maintenant un tout autre exemple de document mais sur lequel on peut se retrouver à bosser après la thèse : il s’agit du CV analytiqueVoir notamment ce billet sur le carnet Hypothèses Academia pour une bonne description de ce type de document.
qu’on doit élaborer pour obtenir la qualification, puis un poste de maître de conférences (en France en tout cas).

Ici, les trois paramètres que j’ai évoqués au début sont inversés. D’abord, le document est beaucoup plus court qu’une thèse – dans mon cas, environ 40 pages. Ensuite, les contenus sont plus divers : il y a un grand nombre d’informations hétérogènes à résumer, ce qui m’a amené notamment à utiliser plusieurs types de listes et de tableaux, ainsi que des encadrés. Enfin, le travail de mise en forme est relativement facile (surtout après le casse-tête de la thèse) : pas d’index ni de folies dans la maquette, juste une myriade de petits réglages typographiques simples à effectuer pour rendre le document confortable à naviguer.

Pour ce travail-là, je n’ai pas utilisé LaTeX mais les technologies du Web. En fait, j’avais fait une première version pour la qualification, avec le texte en Pandoc Markdown et un PDF généré via Pandoc + LaTeX. Or quand j’ai voulu reprendre ce document après seulement quelques semaines, une partie de ma mise en page ne fonctionnait déjà plus. Après un moment d’énervement, puis d’abattement, j’ai décidé de tout remettre à plat. Ça faisait longtemps que je voulais tester Paged.js, et je me suis donc lancé dedans sur un coup de tête.

Pour expliquer brièvement de quoi il retourne, le W3C – qui coordonne le développement des technologies du Web – a créé depuis déjà un moment tout un tas de règles et d’outils pour transformer du HTML classique (= page unique qui défile en continu) en HTML paginé (= fichier sectionné en plusieurs pages, prêt-à-imprimer). Mais les navigateurs traînent à implémenter tout cela. Alors quelques personnes ont conçu Paged.js, un programme JavaScript qui s’occupe de faire la traduction entre nos fichiers, rédigés conformément aux spécifications web-to-print du W3C, et les navigateurs.

Concrètement, j’ai repris mon document Pandoc Markdown, et au lieu de générer un PDF via Pandoc + LaTeX, j’ai généré (toujours via Pandoc) un fichier HTML intégrant le script Paged.js. Puis j’ai ouvert ce fichier HTML dans Google ChromeSafari et Firefox ne gèrent pas certaines règles CSS dont j’avais besoin (maîtrise des sauts de page, des lignes veuves et orphelines…). On pourrait remplacer Chrome (logiciel propriétaire) par Chromium (logiciel libre), et c’est d’ailleurs ce qu’utilise la version ligne de commande de Paged.js.
pour le visualiser et l’enregistrer au format PDF.

Mise à jour 04/04/2023 : vous pouvez retrouver une description technique un peu plus détaillée de ce processus à la fin du billet.

Je suis très satisfait du résultat, autant dans l’expérience utilisateur que dans le rendu final. Quand j’ai essayé de comprendre pourquoi cela avait si bien fonctionné, j’ai compris que c’était parce que les trois paramètres dont j’ai parlé étaient inversés.

D’abord, le fait d’avoir plein de choses à personnaliser met en lumière les qualités de CSS comme langage de mise en page. Dans ce type de situation, la modularité d’un outil comme LaTeX devient source de difficulté, avec un risque croissant d’incompatibilité entre modules. C’est l’usine à gaz. On peut alors être tenté de se coltiner directement le langage sous-jacent pour contourner le problème. Mais TeX est réputé difficile d’accès. À l’inverse, CSS est connu pour être relativement facile à prendre en main. Je trouve même que c’est une interface plus fiable que TeX. Le modèle TeX (boîtes, colle, pénalités) : pas si éloigné de la casse du typographe. (source : Overleaf)Le modèle conceptuel de TeX, celui d’un texte fait de blocs « collés » ensemble, est très élégant, lié à l’histoire de la typographie. Mais le fonctionnement de CSS (sélecteurs, spécificité, héritage, cascade…), fondé sur la structure sémantique et la logique, me paraît beaucoup plus pratique à l’usage. Alors si j’apprécie le côté « pilote automatique » de LaTeX, où on se concentre sur un ou deux problèmes compliqués tandis que le reste est géré automatiquement, je crois que fondamentalement je préfère la possibilité que me donne CSS de tout gérer moi-même sans m’arracher les cheveux.

Et ensuite, mettre en forme un document plus dense (car plus court et plus hétérogène) implique des allers-retours plus fréquents entre le texte et son rendu. Tout ce qui peut réduire la friction inhérente au processus de compilation est alors bon à prendre. Or dans le cas de Paged.js, on peut prévisualiser le résultat final dans le navigateur sans avoir à générer le PDF, simplement en utilisant une feuille de styles qui simule la paginationOn peut trouver une telle feuille de styles dans le dépôt GitLab de Paged.js.
. Dans mon cas, le passage du texte au rendu implique seulement une conversion depuis Markdown vers HTML via Pandoc, très rapide. J’ai aussi utilisé un script de Nicolas Taffin et Sameh Chafik qui fait défiler automatiquement le HTML jusqu’à la dernière page visitée lorsqu’on recharge le fichierNicolas en parle sur son blog. Il qualifie le script d’indispensable ; je confirme.
. Tout ceci rend le processus d’élaboration beaucoup plus confortable.

Je retiens de cette expérience que « le bon outil » dépend des circonstances. C’est peut-être évident pour les lecteurs de ce billet, mais ça ne l’était pas forcément pour moi, qui aime bien adapter un seul outil à différents besoins. Ceci me rend désormais un peu plus curieux d’essayer différents outils pour déterminer dans quelles situations ils brillent particulièrement. Je pense à Quarto, dont je me demande s’il ne pourrait pas remplacer Hugo dans ma pratique ; à Typst, capable de générer un PDF directement dans le navigateur à une vitesse imbattableAlbert Krewinkel, impliqué par ailleurs dans le développement de Pandoc, a partagé ses réflexions sur ce nouvel outil dans un billet récent.
 ; ou encore à Pollen, qui pousse la logique de programmation éditoriale dans ses retranchements avec un pré-processeur qui unifie l’écriture par-delà les formats de fichier.

Je sens aussi que cela a fait évoluer mon rapport à LaTeX. Albert Krewinkel écrivait récemment sur Mastodon que les difficultés rencontrées par beaucoup de gens avec LaTeX révèlent d’abord et avant tout la difficulté inhérente au fait de créer des PDF complexes et soignés. C’est vrai. Il n’empêche que mon opinion est de plus en plus partagée sur cet outil. Je reconnais qu’il y a des efforts pour faire évoluer l’écosystème TeX (je pense notamment à ConTeXt) mais l’expérience de CSS fait grandir en moi une certaine impatience, ainsi qu’une curiosité pour d’autres outils. Les réflexions que j’ai partagées au-dessus illustrent cette évolution. Je n’ai testé Paged.js que brièvement, sur un cas très simple, quand d’autres l’utilisent avec brio pour des projets beaucoup plus complexes. Mais cela m’a suffit pour devenir assez enthousiaste. Le fait de découvrir des ressources comme Hyphenopoly, qui permet de bénéficier du même algorithme de césure que celui de TeX, mais dans un environnement HTML/CSS/JS, achève de me convaincre qu’il faut parfois sortir de sa zone de confort et remettre en question ses certitudes, si ancrées soient-elles.