Dans les recoins de la double page (Paged.js à la maison, saison 2)

Billet publié le 1 mars 2021 par nicolas

Il y a presque deux ans, je présentais ici le making-of d’une collection chez C&F éditions (la collections interventions, qui s’est étoffée depuis) produite avec des logiciels libres et en particulier dans un navigateur web, au moyen du code html, des feuilles de style css et du palliatif (ou polyfill) Paged.js qui supplée au manque de support par les navigateurs web de la spécification du W3C pour les CSS destinées aux médias paginés.
Dans ce post (long), je voudrais raconter la suite des événements et faire le point sur l’état de mes travaux.

Le premier livre que nous avons fait avec Paged.js, (depuis quatre autres titres sont venus enrichir cette collection…)

Le procédé utilisé pour notre premier livre présentait des limites, que j’expliquais alors, surtout en ce qui concerne le flux de texte (le gris typographique, étant donné l’algorithme assez sommaire de justification et les césures souvent inopinées) ; mais sincèrement, on croise parfois des résultats équivalents, sinon pires, en librairie, dès lors que les logiciels PAO n’ont pas été correctement paramétrés. À noter aussi, l’absence de notes de bas de page, pas encore au point, mais qui finalement nous a permis de nous réconcilier un peu avec les notes de fin de section. Ces notes de fin demandent un peu plus de travail au lecteur, mais permettent d’avoir des pages finalement plus harmonieuses. Disons que c’est un arbitrage que nous n’aurions pas fait spontanément, mais que nous avons accepté.

Ce procédé est également tout à fait intéressant à plusieurs égards : d’abord il s’articule à une pratique que nous avons, de recourir massivement aux feuilles de style, toujours nommées de manière sémantique c’est à dire en référence à la motivation et non aux attributs visuels du texte ; ensuite, il nous donne une forme de contrôle, d’ouverture et de disponibilité en exposant le code source du livre dans deux langages que nous aimons pour leur lisibilité : html et css, il s’approche aussi de la publication epub qui est pour nous dans la continuité du livre imprimé, il nous permet aussi de travailler à plusieurs à distance avec git, sans se préoccuper des installations, des licences de logiciels de PAO, et ouvrant le chantier à des non-spécialistes de l’usine à gaz Adobe (comme mon collègue Hervé Le Crosnier ;-). Et puis enfin, il faut reconnaître que c’est irrésistible d’inventorier, de reconstituer et donc de repenser pas-à-pas ses besoins. C’est une bonne pratique de designer, qui permet d’évaluer chaque caractéristique, de prioriser, bref, de ne rien employer qui ne soit nécessaire, sous prétexte que ce serait disponible dans l’interface d’un logiciel.

Je pensais à la fin de ce chantier avoir fait le tour des difficultés principales et pouvoir faire des livres ainsi. C’était bien-sûr mettre de côté la complexité et l’exigence du média paginé, car il ne s’agissait pour le moment que d’un livre de texte simple. Ce qui est vrai pour une collection ne l’est pas pour toutes. La première ligne de crête franchie, je découvrais seulement de là-haut la vraie chaîne de montagnes que nous avions devant nous :-). Mais pour aborder tout cela il faut parler plus spécifiquement d’un autre projet. il s’agit d’avantage d’un manuel d’apprentissage, avec un chapitrage, mais aussi de nombreux éléments accompagnant le texte (figures, définitions, exemples, encadrés, listes etc.) qui viennent le compléter et qu’il est plus difficile de traiter simplement dans le flux du texte principal. Bref, nous voici repartis. Commençons par parler un peu de la manière dont les choses se font.

Des gens, des fichiers et des livres

Un des gros problèmes de la fabrication numérique de livres est l’articulation des différents moments et acteurs éditoriaux avec les logiciels et formats de fichiers. Avec l’auteur, on échange souvent des fichiers de traitement de texte (dans le meilleur des cas, on travaille en mode révision avec l’auteur, dans son traitement de texte, puis on accepte les révisions consensuelles, on y applique des styles, après avoir soigneusement nettoyé tous les enrichissements de texte plus ou moins inopinés). Cet échange ne se fait donc pas encore avec la mise en forme que permet le fichier de PAO, qui est quant à lui beaucoup plus difficile à échanger (pour des raisons de licence, de connaissance, et aussi de ressources à associer, comme les polices, etc). À Chaque étape, on peut avoir des besoins de correction, et la correction du texte peut impacter sa mise en forme à son tour. Une fois le fichier importé et composé dans un logiciel de PAO, on passe par une impression ou un PDF pour corriger des épreuves, mais au moment de décliner sur un autre format, on se trouve confronté au fait que la dernière version, corrigée, est devenue prisonnière du fichier PAO, et que la version de départ, dans le traitement de texte, est devenue obsolète.

Pour éviter ces problèmes, certains ont réfléchi à des flux de production à format pivot (single source). J’ai pu découvrir et pratiquer le flux Métopes de la Maison de la recherche en sciences humaines de l’université de Caen, qui s’articule autour du format pivot XML en TEI, avec des ramifications propriétaires pour coller aux usages de l’industrie : Word de Microsoft pour l’écriture et le stylage, Adobe InDesign pour la mise en page imprimée. Métopes, qui se constitue d’un ensemble de scripts et d’outils, insère entre les deux un fichier XML, qui permet de structurer et de créer ce qu’on appelle une expression, une source unique, interopérable pour toutes les manifestations (html, epub, imprimé, pdf, daisy, etc.). Ce flux apporte des possibilités très inspirantes, et son lot de contraintes : rigueur absolue du XML, double report d’une erreur découverte tardivement, difficulté à s’accommoder de besoins ad-hoc, et la nécessité d’une – relativement solide – formation. De toute manière, on échange pas de fichier XML avec l’auteur, on échange toujours du traitement de texte et des épreuves, et on se charge de reporter d’éventuelles corrections tardives à la fois en PAO et dans le XML.

Le flux Métopes de la Maison de la recherche en sciences humaines de Caen (Site web).

XML est très intéressant, mais s’articule avec des outils d’écriture (traitement de texte, notamment). Or on ne peut faire abstraction de l’aspiration à sortir des traitements de texte, de la multiplication d’outils alternatifs. Inspiré par le html et aussi par les langages de balisage léger, comme Markdown (qui permet de constituer une structure simple de html standard sans avoir à subir visuellement le code, et a été créé pour faciliter l’écriture, ce qu’on appelle le flow, d’un blogueur), je me suis demandé si on ne pourrait pas utiliser le flux html + css pour faire le livre, mais également, pour proposer des modalités d’écriture et d’inclusion de l’auteur et du designer dans un processus éditorial.

Il ne s’agit pas d’automatiser la mise en page, c’est un point sur lequel j’insiste, car les flux html + css ont tendance à faire fantasmer certains éditeurs qui se disent qu’ils vont pouvoir automatiser d’avantage, voire se passer de compositeur. À eux je souhaite bonne chance, surtout s’ils sont un minimum exigeants sur la qualité de composition. Non, c’est une autre manière de composer, tout comme markdown offre une autre manière d’écrire que Word, l’idée restant de fournir au compositeur une palette suffisamment complète pour lui permettre de bien travailler. Les gens, leurs savoir-faire ont toute leur place, et il s’agit plutôt de leur proposer une palette alternative suffisamment complète pour qu’ils et elles puissent s’exprimer.

Ici, il s’agit de permettre une collaboration plus serrée entre l’auteur et le designer-compositeur, en temps réel, avec autant d’itérations que souhaité. C’est utile pour un projet ou le designer intervient très tôt, ou bien quand l’auteur aime la contrainte de s’adapter à une forme finale pour écrire. Ce qui est fréquent par exemple dans la presse, avec des outils propriétaires comme par exemple inCopy d’Adobe, qui permet aux rédacteurs de voir la place assignée à leur copie dans la maquette, et l’état d’avancement des pages.

Bonjour Asciidoc

Mais si Markdown est pratique pour l’écriture de manuscrits simples, il est volontairement et à bon escient limité, et difficile à étendre. Cela signifie qu’il prend en charge des niveaux de titres, paragraphes, citations, listes, et en gros c’est tout. Pas de quoi ajouter des encadrés, des définitions, des exemples et autres éléments documentaires. Mon point de vue : gardons simples les choses simples. Il existe un langage du même type mais mieux adapté à la réalisation de documents structurés pour la documentation et les manuels : Asciidoc. Asciidoc n’est pas une nouveauté, c’est même plutôt un vieux de la vieille qui a été créé en 2002 (!). Il permet d’écrire en balisage léger et d’obtenir par compilation du html (il faut une petite extension pour avoir un html moderne et plus sémantique, car par défaut, Asciidoc produit un html un peu old school et surchargé). Avec Asciidoc, à nous les encadrés, les définitions, les exemples, les tableaux, et une infinité d’autres possibilités, puisqu’il est ouvert à nos propres catégories. Il s’avère donc à la fois beaucoup plus complet (avec l’inconvénient de demander un apprentissage, du coup), et plus extensible, permettant de créer des blocs personnalisés avec une syntaxe très simple.

Attention, ce n’est pas une entrée en religion que je propose ici, simplement Asciidoc est une forme qui me semble plus adaptée à notre type de publication. Le procédé décrit après peut tout à fait fonctionner avec d’autres langages, html, markdown ou autres…

À gauche, le chapitre en Asciidoc, à droite, son rendu avec Paged.js. Nous allons détailler un peu dans cet article ce qui se passe entre les deux, dans ce type d’ouvrage.

J’ai donc commencé par tester si le contenu du manuel que j’avais en projet, et dont l’auteur, Wendy Mackay souhaite avancer l’écriture avec moi, pouvait fonctionner en Asciidoc. Il se trouve que ça convenait vraiment bien. Je n’entre pas dans le détail ici, j’y reviendrai peut-être. L’important à comprendre est que l’auteur peut structurer sémantiquement son manuscrit de manière assez fine, sans avoir à se préoccuper de la mise en forme. Avec une petite astuce, à chaque sauvegarde, on compile le html et si on veut, on le prévisualise dans un navigateur web, avec par exemple un feuille de style css paginée. On s’y croirait.

Le retour des styles

Pas tout à fait. Le stylage ne peut être entièrement automatique, même si une feuille de style assez élaborée a été préparée en amont, il y a parfois des arbitrages à faire, des petites adaptations locales, en particulier avec l’imprimé, car la page, et la double-page, avec leurs limites strictes en hauteur et largeur, leurs marges, imposent leur format, au contraire du scroll infini et de l’élasticité de la page web. Comment donc le compositeur peut-il introduire des changements locaux nécessaires au “calage” a posteriori de sa double page, sans venir mettre sa pagaille dans le manuscrit ou le code source du texte lui-même (en y ajoutant ou déplaçant des éléments, non pas selon les critères logiques, mais selon les critères esthétiques et de plus contingents liés au format précis de sortie).

J’ai pour cela introduit une troisième source. On se retrouve avec trois fichiers : le manuscrit balisé sémantiquement au moyen de Asciidoc, donc, obéissant à sa propre structure, en sections, paragraphes, d’une part, la feuille de style CSS générale d’autre part, qui s’occupe de construire le livre, et une autre CSS liée à la sortie dans un certain format qui permet de cibler certains éléments et de leur ajouter un ajustement local a posteriori.

Le problème est qu’il faut à cette feuille de style pouvoir cibler tous les éléments. Certains sont faciles à attraper au moyen des sélecteurs et en particulier des pseudo-classes :nth… d’autres sont plus difficiles, parce que la structure du code html est profondément modifiée à la volée par Paged.js lorsqu’il crée des pages, découpe le contenu, lui donne de nouveaux contenants…

J’ai donc profité des “hooks” que permet Paged.js, un système astucieux conçu par le brillant développeur Fred Chasen, créateur de Paged.js, qui permet d’insérer ses propres instructions à différents moments dans la chronologie de son traitement du contenu, de son découpage, de sa mise en forme. Pour commencer, afin d’ajouter une petite routine qui repère et identifie certains éléments (figure 1, 2, 3… exemple 1, 2, 3, définition 1, etc.), ainsi que les sections et sous-sections. C’est encore un peu ad-hoc mais on peut l’imaginer personnalisable. Une fois cet étiquetage fait, il est possible d’attraper un élément et de changer ses attributs, dans une feuille de style séparée, nommée tweaks, car réservée aux petits ajustements localisés et circonstanciels.

(récréation) Reload-in-place

Pause : ma première petite fierté est une broutille qui change la vie. Comme vous le savez, lorsqu’on fait une modification de texte ou de style, il faut recharger une page web dans le navigateur pour voir les changements. Avec une page web ordinaire, le navigateur recharge la page, puis se repositionne là où il était dans la page si on avait scrollé. Mais dans le cas d’un livre paginé, il ne le fait pas et se positionne en haut, page 1. C’est embêtant, lorsqu’on corrige la page 128, de devoir sans cesse recharger, attendre puis aller la retrouver à la main, cette page 128, pour voir si la correction est bien apparue.

J’ai donc ajouté une petite extension à Paged.js qui permet après le rechargement, de rejoindre automatiquement, et le plus vite possible la page 128 (ou une autre, sans supplément de prix ;-), sans attendre que la compilation totale du livre soit effectuée. Je vous l’offre, car je la considère indispensable pour mettre au point un livre. On recharge et l’affichage revient là où on en était, sans attendre que le livre entier soit compilé. Indispensable (fin de la pause).

Dans cette petite vidéo, on voit que si on va sur une page, puis qu’on recharge le navigateur, la fenêtre rejoint automatiquement cette dernière page vue, pendant la compilation Paged.js.

Traits de coupe, débord et double page

Une nouveauté du dernier titre de la collection interventions, c’étaient des intercalaires illustrés en double page entre les parties du livre. J’ai pu bénéficier du travail de Julie Blanc et Julien Taquet sur l’interface de Paged.js qui proposent de faire apparaître une zone de débord autour de la page, avec des traits de coupe.

Pour mettre une image en double page, j’ai en réalité positionné deux grands blocs, un sur chaque page, débordant dans la zone de coupe, et importé deux fois mon illustration. La feuille de style calcule, en fonction de la présence de ce type de bloc sur la page de gauche ou de droite, le décalage d’image qui permet de positionner les deux morceaux bord à bord. Vive les css calc() et les variables.

Une double page avec illustration sur deux pages, débords et traits de coupe (on ne les voit pas bien avec cette trame, mais ils y sont).

Mais la présence de cette zone de débord, avec les traits de coupe directement dans Paged.js (et non plus ajoutés a posteriori au PDF) permet d’envisager et de réaliser toutes sortes de nouvelles disposition qui sortent de l’empagement, et donc du livre de texte pur et dur.

Encadrés

La deuxième chose nouvelle dont j’avais besoin pour ce projet, c’étaient des blocs qui glissent hors du texte, dans la marge, mais avec des comportements parfois différents.
Certains, comme des notes marginales doivent suivre le paragraphe auquel elles sont ancrées. C’est le cas ici aussi pour les légendes de figures. Pour ces éléments, j’ai opté pour un positionnement absolu, relatif à leur parent (pour la hauteur) et un comportement légèrement différent sur les pages de gauche ou de droite, avec le même résultat, ils sont dans la marge extérieure (le grand fond).

Mais d’autres sont un peu différents. On peut imaginer des encadrés, qui se positionnent de manière absolue dans la marge, par rapport à la page, et non à leur point d’insertion dans le manuscrit. Mais il peuvent aussi être plusieurs, et dans ce cas, il ne faut pas qu’ils se superposent mais bien qu’ils se juxtaposent. J’ai opté pour la création d’un conteneur pour eux dans la zone de marge de Paged.js elle-même, un hook les retire du flux de texte et les déplacer, un par un, dans cette zone.

C’est un troisième type d’encadré qui pose le plus de difficulté finalement, les grands encadrés insérés dans le texte lui-même. En effet, ces grands encadrés trouvent une place précise dans le manuscrit, mais dans une page, ou double-page, ça ne se passe pas comme ça…

Sur ces quatre pages, de gauche à droite, quelques exemples éléments qui peuvent venir dans la marge : 1. à gauche, la légende de la roue colorée apparaît à la hauteur de la figure, comme 4. les notes marginales qui sont bien alignées sur tel ou tel paragraphe. Mais au centre : 2. La liste est positionnée en haut de page et 3. l’encadré aussi.

Flottements

Tant qu’un livre ne contient qu’un texte en effet, tout se passe bien, mais certains éléments (textuels ou iconographiques) ont un statut particulier qui peut les détacher du texte. Il peut s’agir de notes par exemple, dont on voit bien qu’elles sont un renvoi au sein du texte principal vers un petit fragment de texte qui en est précisément extrait pour être renvoyé à la fin de l’ouvrage, de la section, ou bien, et c’est là que ça devient intéressant, à une région particulière de la page : en bas pour les notes de bas de page, ou dans une marge pour des notes marginales, des gloses…

Ce n’est pas tout : il y a aussi des figures, tableaux et certains encadrés qui figurent dans le texte mais ne tombent d’ailleurs pas toujours bien, une fois placés dans l’espace borné de la page. Par exemple, un encadré peut arriver à cheval sur deux pages. Dans ce cas, il faut la sortir du texte, et le faire “nager” jusqu’au haut de la page suivante par exemple, tout en faisant passer une portion de texte correspondante, sous l’encadré, pour la rattacher au texte la précédent et combler le vide. Cela se fait en PAO au moyen des blocs ancrés, et avec LaTeX des éléments flottants (floats). En CSS, la chose est aussi prévue depuis 2015, avec des possibilités très intéressantes, mais pas du tout implémentées pour le moment. Paged.js pourrait s’y pencher prochainement. En attendant, pouvions-nous y palier au moyen d’un de ces Hooks ?

L’encadré gris était coupé, à cheval sur deux pages. On va plutôt le positionner en haut de la page suivante et faire passer tout un titre et un paragraphe “avant” lui pour éviter un grand blanc en bas de la page de gauche, si la lecture le permet.

Encore une fois, j’ai pu bénéficier du travail de de Julie Blanc qui s’intéresse à la question depuis un moment et avait déjà publié un article complet et même un petit script pour pousser les encadrés en haut de page suivante dans une de leurs précédentes expérience. J’ai de mon côté travaillé dessus pour obtenir deux modifications importantes à mes yeux : d’une part plusieurs possibilités (quatre en tout, pour atteindre les quatre extrémités de la double page, décrites ainsi : la même page en pied, et en tête, la page suivante en pied et en tête – on ne peut pas revenir à la page précédente, déjà composée par le script, et d’autre part, une manière de le faire correspondant à mon approche, en effet je ne pouvais me permettre de déclencher cette migration par l’ajout d’une classe dans le html. Laissez-moi vous expliquer pourquoi.

L’article de Julie Blanc sur le site de Pagedjs.org.

Les scripts proposés par les talentueux développeurs de Paged.js Julie Blanc et Julien Taquet s’appuient souvent sur une classe qui déclenche tel ou tel comportement, c’est simple, efficace… mais c’était précisément en contradiction avec ma ligne directrice : essayer de ne pas avoir à changer l’ordre des éléments dans le texte / code source, ni d’ajouter de classe motivée par le graphisme, de classe qui ne soit pas sémantiquement justifiée dans le manuscrit source. Ce source, qui est en Asciidoc et même pas en html, dans un format d’écriture, donc, que j’essaie de réserver à l’auteur.

La ligne du parti

C’est bien une opération intentionnelle du compositeur qui permet de sortir un bloc du flux de texte et de choisir sa destination. Une decision au vu de la double page, d’en améliorer l’aspect. J’ai donc proposé une css dévolue à cet usage. Le designer dispose ainsi de deux feuilles de style : une pour la composition générale, et donc “automatique”, applicable à l’ensemble du manuscrit, et cette autre, nommée tweaks.css pour procéder à des ajustements au vu du résultat une fois composé. Même si on peut définir des règles automatiques pour ne pas couper une figure, la décision sur l’emplacement d’un bloc en “page float” se fait à ce moment là, a posteriori. Tout comme peuvent l’être d’autres détails et petits ajustements qui permettront de gagner deux lignes par ici, aligner un élément sur un autre, ou à l’inverse de le pousser un peu plus loin. L’idée est de bien retrouver les deux temps de la composition : celui que le designer consacre à l’élaboration de son gabarit et de ses feuilles de style, et qui vont accueillir le contenu dans l’espace de la double page, et celui où il décide, au vu du rendu de telle ou telle page, de procéder à quelques aménagements. On peut tout à fait imaginer que l’auteur fait de même de son côté, en modifiant un peu son manuscrit en fonction de l’aperçu qu’il obtient de son texte une fois mis en page (par exemple pour équilibrer la longueur de deux définitions, pour parce qu’une légende prend trop de place, etc.) En effet, certains auteurs écrivent avec des contraintes de forme, soit parce qu’ils aiment ça et que ça les stimule, d’écrire pour tel ou tel cadre, soit parce que leur media les y contraint franchement (les rédacteurs de presse se reconnaîtront). Nous avons ces quatre temps actifs de publication :

le temps de la rédaction (et de l’illustration)
le temps de la maquette
la retouche par le rédacteur
la retouche par le compositeur

L’auteur et le designer travaillent ensemble sur le livre, chacun a ses fichiers. Au vu de la mise en page, chacun peut décider de changer des choses, l’auteur peut couper du texte par exemple, le designer peut déplacer des éléments, ajuster localement ses règles de mise en page, mais en évitant d’intervenir dans le fichier de l’auteur pour cela.

Chaque temps s’effectue autant que possible dans le fichier le plus adapté, ce qui évite à un des acteurs d’avoir à trouver des modifications inopinées, venues d’un tiers, et une syntaxe qui ne lui appartiennent pas dans son fichier. Cela simplifie en outre la gestion de versions de fichier, puisque cela réduit les risques de conflit de version (les fichiers sont synchronisés entre auteur et designer via NextCloud à ce stade). On peut imaginer un éditeur de fichiers qui donne à chacun un espace de travail sur ses fichiers et un aperçu commun du résultat.

De gauche à droite, les fichiers, le texte source qui va donner le html (et que l’auteur a appris à écrire en Asciidoc), la css principale qui donne les règles de la mise en page, et la css de “tweaks” qui permet de modifier la position et l’apparence de certains éléments de la page a posteriori. Tout est synchronisé via NextCloud pour le moment, et comme chacun s’occupe de ses fichiers, ça fonctionne sans accroc, même si on peut améliorer.

Tout ça est bien en théorie, en pratique c’est plus difficile. D’abord le fait d’utiliser une compilation en html5s pour le html rendu à partir d’Asciidoc fait perdre les identifiants. Asciidoc étiquetait de manière assez utopique, tous les éléments au moyen d’un id numérique. Utopique puisque chaque modification (ajout d’un paragraphe par exemple) modifiait l’ensemble des numéros (Paged.js fait de même). Mais pour que la css tweaks du designer fonctionne, il faut que celui-ci puisse désigner (sélectionner en terminologie css) de manière fiable et pérenne l’élément visé.

Attrape-moi si tu peux

Une syntaxe permet en théorie de se passer d’identifiants, les sélécteurs de type nth-child qui combinés avec des chiffres et lettres, permettent en théorie de cibler des éléments sans classe et sans nom
par exemple l’avant dernier paragraphe de la troisieme section s’écrirait :

section:nth-child(3) > p:nth-last-child(2) { jolie: css; }

ou les lignes paires du deuxième tableau tableau à partir de la 6e :

table:nth-child(2) tr:nth-child(2n+6) { jolie: css; }

Cela convient dans certains cas (bien que peu pérenne, un changement en amont pouvant bousculer ce comptage) et ça s’applique assez bien au DOM du code source du manuscrit. Mais c’est plus difficile avec le DOM paginé une fois rendu par Paged.js. Un exemple : Paged.js coupe les sections au fil des pages, et c’est bien normal, mais, il les réécrit au sein de chaque page. Ces sections se retrouvent donc multipliées dans le DOM, autant de fois qu’elles parcourent de pages. Ainsi un document d’une section sur six pages contiendra six pages avec six sections enfant. ça complique vraiment les choses pour compter au vu du résultat, et ça bouge pas mal.

J’ai donc commencé par créer une petite routine en Hook qui attribue un ID correspondant à la numérotation des éléments, figure 1, figure 2,… tableau 1, tableau 2,… exemple 1, exemple 2. Les sections aussi sont identifiées en fonction du nom de leur titre (h2) et de leur numéro d’ordre. Ainsi il devient possible de cibler une figure, pour lui assigner une propriété page-float, dans l’idéal. Car comme cela n’existe pas encore vraiment, j’ai besoin d’une classe pour déclencher le script. Ça donnerait donc en théorie :

#image-block_5 { .page-float-next-top; /* on ne peut pas faire ça */ }

Mais on ne peut pas inclure une classe CSS dans un ensemble de propriétés comme on peut le faire en LESS ou SASS par exemple, ce qui serait pratique. De toute manière ce que fait LESS dans ce cas est simplement d’aller chercher les propriétés et leurs valeurs de la classe indiquée et de les rapatrier dans l’ensemble qui les appelle. Il n’étiquette pas l’élément du DOM avec ladite classe. Or c’est ce qu’il me faudrait : partir d’une css pour ajouter une classe dans le DOM.

J’ai donc (avec l’aide de Julien Taquet, parce que tout seul j’aurais eu du mal) écrit un petit script qui s’exécute juste avant Paged.js et qui va ajouter ces classes dans le DOM en fonction de ce qui est déclaré dans tweaks.css pour que Paged.js (et son hook consacré aux page-floats) les repèrent et opèrent le substitut de page-float. Pour cela, et à titre de preuve de concept, j’ai donc carrément créé une propriété css à moi (propriétaire donc), qui serait à retravailler sur le modèle du working draft du W3C, mais qui très temporairement s’appelle –taffin-page-float, et qui peut prendre quatre valeurs : same-top, same-bottom, next-top, next-bottom. ce qui donne dans tweaks.css

#image-block_5 { --taffin-page-float: next-top; }

et qui permet à la fois d’ajouter la classe dans le DOM, sans intervenir sur le manuscrit, puis de déclencher le comportement du hook réservé à ce type de page float (position en premier dans le contenu de la page suivante : en gros, les blocs qui vont en haut sont déplacés par le script, ceux qui vont en bas sont positionnés de manière absolue). Ouf. Ça parait un peu compliqué comme ça, mais cela suit la logique proposée, et ça marche, modulo une bonne gestion de la chronologie des événements par le script. Je ne remercierai jamais assez Julien Taquet pour son aide et sa fine connaissance de Paged.js.

La partie du petit script qui modifie les éléments du html en fonction de la valeur qu’il trouve pour la propriété –taffin-page-float

Sur cette base et quelques bugs plus tard, j’ai pu produire mon chapitre de manuel, avec grosso modo tous les petits raffinements nécessaires. Je voulais documenter un peu l’approche, c’est pour cela que j’ai écrit ce post.

Un dernier petit avant-après pour la route.

Prochaines étapes

Les codes sources sont ouverts et je peux les proposer à la communauté, je les ai déjà transmis à mes complices à qui je suis tant redevable, comme je l’ai fait pour le Reload-in-place si utile au quotidien, même si je voudrais encore prendre le temps de finaliser des choses avant, et notamment changer le fonctionnement (et le nom) de la propriété propriétaire :-)

Je voudrais aussi confronter ce fonctionnement à d’avantage de chapitres / modèles, bref, prendre un peu de temps, car c’est ainsi que les choses se consolident, se complexifient, puis se simplifient. Pas si évident de contribuer utilement à un projet libre, c’est un investissement important et le syndrome de l’imposteur guette.

Mais enfin, l’idée est maintenant de se glisser dans un flux, un éditeur un peu plus intégré, soit en s’appuyant comme je le fais actuellement sur une plateforme, comme VSCode, soit de préférence en utilisant le navigateur web comme environnement de travail. Là encore je ne suis pas le seul à y penser, il y a par exemple l’astucieux printcss.live de Andreas Zettl, Stolon de Raphaël Bastide, ou même Editoria. Il serait possible de partir d’une base et de la modifier à titre de contribution, quand la licence le permet. Car tout cela ajoute un autre niveau de complexité (gestion des fichiers et des droits essentiellement) et j’aurai besoin d’aide. Voilà voilà, pour le moment, désolé pour le long post. Questions ou commentaires bienvenus !

Ce a quoi pourrait ressembler un éditeur connecté, permettant à l’auteur d’écrire, et au designer de mettre en forme, ensemble et simultanément. Y’a plus qu’à.

Portrait en creux

Billet publié le 6 décembre 2020 par nicolas

Le 2 décembre 2020, Olivier Taffin, mon père, est mort à Marseille où il habitait, cédant à son emphysème pulmonaire. J’étais si habitué à nos petits rituels de papa et de fiston, au fait qu’il avait une vie publique bien avant moi, à nos conversations, même discontinues, à sa manière de vouloir toujours parler de l’essentiel tout en essayant de nous rassurer, et donc d’esquiver en souplesse, que j’en ai oublié de dire qui il était. Je ne pensais pas qu’il avait besoin de moi pour ça. Je me suis peut-être trompé. Et c’est peut-être moi qui en ai besoin. Alors je vais jeter trois mots ici. Des impressions plutôt que des faits, qu’on trouve bien listés sur sa page Wikipedia. Ou des images, il y en a plein de ses toiles sur son site, et pour la BD je reviendrai bientôt.

Olivier avait soixante quatorze ans et était artiste. Il avait plusieurs modes d’expression et de création, trop peut-être, pour dire en une fois : peintre, sculpteur, cinéaste, dessinateur, auteur de chansons, de romans, de théâtre et d’opéra, prof municipal de dessin, et peintre encore, chanteur enfin, pour ce dont je me souviens. Mais moi je l’ai connu tard, déjà, à vingt quatre ans. J’ai manqué ses années 50 et 60…

Il n’était pas artiste pour le plaisir de faire des choses créatives avec ses doigts, il était artiste de cette nécessité intime et violente qui rend le travail artistique lui-même pénible. Avec ses obsessions, sa difficulté à s’y mettre, son angoisse insoluble dans la bière ou le jaja, ses cigarettes fumées accroupi à évaluer ses créatures en devenir posées sur les tomettes. Il était artiste pour guérir ses plaies de l’âme, son adolescence pénible, la perte de son frère, ses espoirs déçus, mais jamais trahis, d’utopiste né à nouveau en 1968, son désir frustré de reconnaissance, autonome par contrainte, mais indépendant par volonté, érotomane de l’imaginaire, retourneur d’images, amoureux de paroles, de sa femme, de son quotidien, de ses enfants. Nostagique plusieurs fois expulsé de son passé.

Pris dans ses nécessités intérieures, il peinait à choisir son champ, à chercher à plaire, à communiquer ses œuvres, et à s’insérer dans le monde organisé des choses identifiées. Il s’appauvrissait à force de chercher partout sauf là où est l’argent, même dans le monde de l’art. Il ne savait pas se faire entreprise, obtenir des subventions, plaire aux dracs. Il produisait peu, ruminait beaucoup, prenait son temps sans vraiment le vouloir. Ce temps, qu’il préférait toujours à l’argent, en faisait quelqu’un d’abordable dans un monde de gens pressés, un peu comme dans un film où tout le monde passe en accéléré sauf un personnage qui est au ralenti.

Angoissé plus que bougon, désespéré, doux, attentif, curieux. C’est un drôle d’équilibre, de mélanger tout ça avec l’exigence d’authenticité et le refus des concessions. Sa manière d’être père : me recadrer à chaque fois qu’il sentait que je me perdais de vue ou me trahissais par des choix superficiels ou une attirance pour la facilité, et me câliner quand je lui annonçais un truc comme un ènième redoublement… Un peu Jedi, mais sans la mystique.

Car l’enfance est le lieu des mythologies. Vous en voulez ? J’ai déjà raconté le paradis perdu de ma petite enfance, en 2005, mais j’ai encore de l’épique en tête. En voilà un paragraphe. Quand il m’apprenait à faire bouger les dessins dans un petit carnet rien qu’en le feuilletant, et aussi avec une caméra super 8. Quand je déballais fièrement un malabar dans la cour de récré pour montrer à mes copains le petit comic qu’il avait fait dans l’emballage. Mes mercredis, samedis et dimanche dans l’atelier de BD de l’impasse Bergame, que je passais dans la mezzanine au dessus des dessinateurs Cabanes, Lacaf, Loisel, qui inventaient avec lui la BD pour adultes, et lisant des choses pas du tout de mon âge en respirant leur fumée. Des soirs sous l’édredon, avec un peu de buée qui sort de la bouche, lisant à la lueur de la lampe à pétrole quand EDF avait coupé l’électricité, ou quand le proprio esthète venait se servir en tableaux pour suppléer au loyer. Quand je m’endormais dans les fêtes et les vernissages après avoir bien mangé. Mais malgré ça j’étais tellement gâté, le boîtier Olympus d’occasion pour faire mes premières photos, l’apprentissage du labo pour les développer, ou l’ordinateur Sinclair alors que je réclamais depuis des mois une console comme les autres gamins : « Tu n’as qu’à les programmer, si tu veux des jeux », cadeau comploté avec ma mère, quand ils étaient divorcés mais encore alliés pour me faire plaisir. Je me souviens de ma bouderie quand il reconstruisait sa vie avec Cornelia et que moi je l’aimais bien, la galère bohème d’avant. Ces journées France Inter. Je me souviens de nos voyages invraisemblables, en 2CV enfant, ou en DS adolescent avec le vomi du chat et de Juliette en alternance continue. Ou de cette transhumance dans un camion fou avec Richard pour poser la famille et ses meubles expulsés de Paris à la campagne. Cette belle maison au bord de la rivière, ses filles Juliette et Lucie heureuses et musiciennes, que je voyais de moins en moins. Je me souviens du jour où il voulait revenir à Paris mais n’en avait plus les moyens immobiliers, que je lui ai dit : « Tu devrais aller voir Marseille, ça te plairait, c’est pas la province, c’est autre chose, un peu comme le vingtième ».

On pouvait se confier à lui, sur l’essentiel. Qu’on soit une enfant, un adolescent, un adulte ou une vieillarde. L’accessoire l’intéressait peu. Personne se s’y trompait et il avait de nombreux amis d’une vie, indétachables, ou copains d’un comptoir. Il devait aussi faire fuir, pour ces raisons, celles et ceux que ça angoisse et qui préfèrent se blottir au creux des choses. Les autres, il les régalait avec des délices de la table, si centrale que la journée entière s’organisait autour d’elle.

Un portrait pareil est sans doute raté : j’imagine que celles et ceux qui le connaissent déjà le trouveront un peu ressemblant, et qu’il restera un mystérieux brouillard pour les autres. J’ai vécu toute ma vie jusque là avec un Olivier splendide arbre dans mon jardin mental. Je ne me rends pas encore vraiment compte de ce que va donner la vue sur l’autoroute, maintenant qu’il est abattu. Je pense à ses amours, les mères de ma vie, mes sœurs, ses petites filles.

[màj] Au cours du mois de décembre 2020, si vous souhaitez participer à ses obsèques, vous pouvez vous joindre à une petite cagnotte.

Dystopies familières

Billet publié le 21 septembre 2020 par nicolas

François Houste est un type formidable : non seulement il a du talent et de la finesse, mais en plus travailler avec lui est un grand plaisir. C’est sans doute pour cela qu’il inaugure la collection fictions de C&F éditions ;-)

Mikrodystopies, ce sont des moments volés au futur (un futur si présent), des situations, plus que des histoires, qui montrent les humains confrontés à leur devenir-machine, les algorithmes face à des dilemmes humains trop humains, les robots désireux de se faire une place dans l’humanité, bref, un joyeux méli-mélo de notre quotidien techno-futur. 320 fragments de vies, tous limités à 280 caractères – pas un de plus – un exercice de style inspiré et stimulé par Twitter où le compte @mikrodystopies poursuit ses explorations. Le ton est toujours aigre-doux, plein de finesse, d’humour aussi. Quant au désespoir, n’est pas une injonction, il est laissé à la discrétion du lecteur, qui affichera d’abord bien souvent un sourire.

Le livre, lui, s’est composé avec beaucoup d’harmonie dans les échanges : sélection de petits fragments, ajouts, retraits (quand on ressentait des répétitions à la lecture), déplacements, corrections, choix du caractère (le magnifique faux monospace Attribute Text de Viktor Nübel) et mise en forme (la composition est centrée, et rythmée manuellement, ligne par ligne, imitant une diction, réalisée avec Sophie Harris) ; tout cela se faisait avec décontraction et une vraie complicité auteur-éditeurs. La couverture finalement choisie représente comme sur la vieille VHS du salon, cette faculté d’avance-rapide-jusqu’à-la-fin que nous procure le livre.

Mais j’avais en tête une série de photos depuis un moment, cela a été l’occasion de passer à l’acte. L’idée en était : produire “à la maison” et sans effets de retouche, ni collages impressionnant, ni équipements futuristes, des images mettant en situation tous ces messages numériques qui nous confrontent aux erreurs systèmes, illegal arguments et autres plantages, violations des termes, acceptation de conditions abusives ; bref, à la régulation de nos vies par les logiciels depuis que « Code is law ». J’ai donc profité de l’occasion pour acquérir un nano projecteur à trois sous que j’ai rendu complètement myope en lui collant deux bonnettes. Puis j’ai préparé des messages que nous avons pu projeter, avec l’aide de ma fille, sur les jouets, murs, objets de la maison, ou même sur notre propre peau, comme s’ils étaient animés de facultés interactives nouvelles, irrigués de silicium. Avec un peu d’imagination, bien-sûr. C’était amusant de se contorsionner avec tout cet équipement dans des petits coins de la maison. J’ai aussi pu faire quelques images chez ma mère, dont l’intérieur n’a vraiment rien de techno, et lui proposer ainsi une belle mise à jour. Bref, on était vraiment dans le quotidien familial, tout près des récits de François Houste.

Je me retrouvais avec une série de 11 images finales, sombres mais familières, qui ont rapidement trouvé leur pendant dans les Mikrodystopies. Plus que des illustrations strictes, cela composait des paires harmonieuses, que nous avons mises en valeur dans certaines doubles pages du livre.

Techniquement, nous souhaitions aussi conserver le lien entre le fragment et le tweet d’origine sur le compte @mikrodystopies. Chaque fragment a été numéroté, et l’auteur a bien voulu nous transmettre l’URL du tweet originel. Avec cette table des tweets utilisable en ligne, il était ensuite possible de conserver un lien entre la version imprimée et son pendant en ligne, par exemple pour réagir, retweeter ses préférés, etc.

Nous avons aussi imaginé d’autres possibilités, comme celle de proposer aux lecteurs et lectrices de produire leurs propres mikrodystopie, en texte ou en image, cela va se passer ici très prochainement https://cfeditions.com/mikrodystopies/

François Houste, Mikrodystopies,
C&F éditions, 15 €
ISBN 978-2-37662-011-2
Extrait gratuit et achat : https://cfeditions.com/mikrodystopies/

À noter : l’auteur dédicacera son livre à l’occasion d’un pot de parution à Paris -> jeudi 24 septembre, entre 18h30 et 20h, au 28 rue de Lagny, 75020 Paris. Apéro, masques et gestes barrières en prime.

Une constellation…

Billet publié le 28 mai 2019 par nicolas

Ce petit billet rapide, parce que je viens de réparer un petit objet web réalisé l’an passé, Constellation, qui était cassé depuis un moment, suite à un changement dans l’API de Gallica que je n’avais pas repéré. C’est ça le web, ça vieillit vite, et la plupart des choses que j’ai commises ont fini par disparaître. Bon, on maintient ce qu’on peut, quand on peut… En tout cas, ce qui m’a fait plaisir c’est de voir toutes ces réactions sympathique à sa réouverture !

Le titre est grossièrement volé à Mallarmé, dans Un coup de dés jamais n’abolira le hasard, parce que la précision d’un moteur de recherche ne surmontera pas notre désir de flânerie et de découverte. J’ai imaginé ces étagères infinies de livres sur lesquelles on en prendrait un au hasard. Un coup de dés.

Constellation, qui est ici (et qui ne mérite pas d’explication particulière pour jouer avec, en fait) est une interface sur les ouvrages scientifiques proposés par Gallica, qui, au contraire du très bon moteur de recherche fourni par Gallica même, ne permet pas de trouver ce qu’on cherche, mais précisément ce qu’on ne cherche pas. Elle invite à fouiller dedans comme chez un bouquiniste, et à laisser faire le hasard, ou l’obstination… Personnellement, ça me fascine et j’aime bien saisir un ouvrage sur ses rayons, j’y fais des découvertes, et je m’amuse souvent.

Car c’est aussi intriguant de voir à quel point ce qui relevait de la science la plus sérieuse il y a un siècle, prête parfois à sourire maintenant. On peut imaginer qu’il en sera de même plus tard avec ce que nous écrivons aujourd’hui le plus doctement du monde.

Le projet a été réalisé pour les 50 ans d’Inria. Cette bibliothèque imaginaire, virtuellement infinie, vous propose donc de passer les cinquante prochaines années dans la lecture d’ouvrages scientifiques… Inspirée par Borges, Queneau et Mallarmé, elle pose sur ses étagères environ 13000 ouvrages scientifiques de la Bibliothèque nationale de France, complètement accessibles numériquement par Gallica. Mais cette quantité augmente rapidement et qui sait combien d’ouvrages seront disponibles quand vous en serez au dernier ?

Making-of d’une collection libérée : Addictions sur ordonnance

Billet publié le 10 février 2019 par nicolas

Est-ce un hasard si nous avons attendu un livre sur le thème de l’addiction pour changer notre manière de faire des livres et employer des logiciels libres de bout en bout ? Pas sûr. En effet depuis la PAO nous nous sommes habitués à un flux de production devenu traditionnel et dont nous avons dit ailleurs à quel point il pouvait devenir problématique. Ce post raconte l’histoire d’une collection que nous désirions depuis un moment produire avec les techniques ouvertes du web. Car oui, on peut aussi fabriquer un livre dans son navigateur. Making-of.

Une collection neuve

Addiction sur ordonnance est le premier volume de la collection interventions. Petits volumes à petit prix et à pagination raisonnable (autour de 128 pages), cette collection aborde des sujets chauds d’actualité pour lesquels C&F Éditions peut apporter les lumières qu’elle sait apporter, avec toujours une forme originale et soignée. Vous pouvez le voir ici.

Le cœur de l’ouvrage est l’enquête de Patrick Radden Keefe « Un empire bâti sur la douleur », et est assorti d’un dossier. C’est le récit impressionnant de la résistible ascension de la famille Sackler, Arthur et ses frères, experts en marketing ayant acquis un petit laboratoire pharmaceutique et modifié sa production pour devenir milliardaires en vendant légalement la drogue la plus addictive qui soit : les opioïdes de synthèse. Ils ont abouti en quelques années au double résultat stupéfiant, si j’ose dire, d’une fortune colossale, agrémentée d’une image de philanthropes, et surtout d’une catastrophe sanitaire sans précédent avec plus de 400000 morts aux États-Unis. Et ce n’est pas fini, l’entreprise étant aujourd’hui en quête d’expansion sur le marché mondial pour étendre ses profits (et forcément ses dégâts).

Nous avions le projet depuis quelques années de développer une collection produite différemment, avec des outils ouverts et libres, et un flux de production plus collaboratif, qui permette par exemple de travailler en collectif très rapidement sur de petits ouvrages produits à chaud, au plus près de l’événement. Mais toujours dans l’urgence, il n’est pas si évident de faire de la R&D pour une petite structure poussée par son programme éditorial ambitieux et limitée par des moyens restreints. Mais nous avons finalement tenu la promesse que nous nous étions faite, et cet ouvrage inaugure le procédé. il faut noter que nous sommes également dans le même esprit que celui qui nous a fait élaborer la licence édition équitable qui défend les droits de nos lecteurs.

Des différentes manières de faire un livre

Enseignant l’édition dans le master d’édition de l’Université de Caen, je m’intéresse évidemment de très près aux différentes manières de faire des livres. Je rêve même de vous raconter tout ça un jour, car c’est un sujet passionnant et qui n’est vraiment abordé dans aucun manuel, à ma connaissance. En voici quelques unes, par exemple :

On peut faire des livres avec des caractères en plomb dans un composteur, et les imprimer sur une presse typographique. Vous croyez que je plaisante ? Regardez ce que fait Jean-Renaud Dagon au Cadratin par exemple.
On peut utiliser un outil de PAO WYSIWYG propriétaire comme InDesign ou Quark Xpress ou le nouveau venu Affinity Publisher, c’est la manière la plus répandue aujourd’hui.
On peut aussi utiliser un outil de PAO sémantique propriétaire comme FrameMaker. Il était le roi du temps où on imprimait de gros manuels d’utilisation, qu’on glissait dans les emballages du matériel et du logiciel par exemple.
On peut encore utiliser le logiciel libre balisé LaTeX. C’est l’outil de prédilection des scientifiques et des chercheurs pour leurs articles et thèses, et certains éditeurs l’emploient, comme O’Reilly ou Le Robert. C’est pointu, c’est sérieux et ça marche.
On peut également utiliser le logiciel libre WYWIWYG Scribus, si non a pas trop de notes de bas de page. Il est prometteur, mais son développement est très lent et desservi par des bugs.
À la fac, par exemple, nous utilisons le flux Métopes du pôle document numérique. Il est basé sur XML-TEI, permet de produire un fichier pivot pérenne et interopérable, tout en bénéficiant du savoir faire des maquettiste et de terminer la manifestation imprimée dans une maquette InDesign.
Enfin (mais cet “enfin” ne concerne que cette petite liste partielle et ne clôt certainement pas les différentes manières de faire un livre), les CSS étant très au point, on peut utiliser le code html + css et tenter de générer un PDF, soit au moyen du logiciel propriétaire Prince, qui existe depuis une bonne dizaine d’années, et est assez efficace, soit au moyen du nouveau venu sous licence libre (MIT) : Paged.js. C’est cette toute dernière solution que j’ai choisi de tester pour réaliser ce livre, car j’avais envie de voir ce qu’on peut faire dans un navigateur web. Il existe d’autres logiciels dans cette branche, comme par exemple les outils HTML2PRINT produits par la talentueuse équipe OSP.

On pourrait et on devrait continuer ce panorama, et une page ressources a été ouverte par prepostprint. On pourra aussi se perdre dans la timeline réalisée par Julie Blanc.

La timeline de Julie Blanc.

Paged media

Paged.js est un ensemble de scripts javascript qui est destiné à compléter le fonctionnement des navigateurs web afin qu’ils supportent mieux les spécifications CSS du W3C pour réaliser des feuilles de styles destinées aux médias paginés. Ce genre de patch s’appele un polyfill. Il essaie de combler les trous, ce qui est d’autant plus nécessaire qu’il semble qu’un certain lobbying s’exerce au sein du W3C pour ralentir cet aspect (par exemple Håkon Wium Lie, le patron de Prince, logiciel propriétaire, a fait tout ce qu’il pouvait contre CSS Regions et obtenu son abandon). Car en théorie, on peut vraiment faire de la PAO correctement avec CSS, on y prend même goût et cela rend des outils comme InDesign bien laborieux et obsolètes.

Paged.js est donc produit par la Fondation Coko (pour collaborative knowledge) de Adam Hyde, gourou voyageur des Booksprints et des Flossmanuals. Qui cherche à produire des méthodes, des flux et des plateformes de production de publications, ciblant notamment le monde académique, mais pas que. Paged.js est ainsi une brique au sein d’un projet plus large : Editoria. Deux de mes amis ont rejoint sa petite équipe : Julien Taquet et Julie Blanc. Le développement est assuré par Fred Chasen. Tous deux sont extrêmement passionnés et compétents dans ce domaine, et on se retrouve parfois au sein du collectif Pre post print imaginé par Sarah Garcin et Raphaël Bastide, autres grands talents du design libre et alternatif. Voilà pour la photo de famille.

Bon, avant de me lancer, j’ai pris le temps de préparer la couverture avec Inkscape, logiciel libre très convainquant, et mérite qu’on y passe le temps d’apprentissage un peu rugueux qu’il demande, tout en restant proche de la PAO traditionnelle et du logiciel de dessin vectoriel concurrent que je ne nommerai pas.

La couverture dans inkscape.

Se lancer avec Paged.js

Le logo de Paged.js.

Avant de commencer, RTFM (Read the fucking manual) semble une approche nécessaire mais insuffisante : en plein développement, Paged.js ne bénéficie que d’une documentation assez sommaire. On peut télécharger l’outil sur le Gitlab de paged media. Et ainsi bénéficier du contact avec les développeurs.

Mon choix initial étant de respecter le précepte de Richard Stallman selon lequel il n’est pas si bien d’utiliser un logiciel libre sur un OS privateur, j’ai installé linux Xubuntu sur une machine virtuelle, ce qui est très bien pour commencer. Xubuntu a l’avantage d’être léger, sans effets graphiques, et très facile à installer. On peut avec VirtualBox créer facilement un pc virtuel sur un mac, si on ne dispose pas de PC. Cela permet d’apprendre le logiciel libre et de s’y essayer quand on est un graphiste, souvent équipé d’un mac. Les performances sont un peu moins bonnes que sur un petit PC. Ensuite il est toujours temps de passer sur une vraie machine. Je pourrai vous raconter ça dans un autre post si ça vous intéresse (signalez-le en commentaire) et Davduf a produit une très jolie Petite histoire d’une libération personnelle.

Cuisine et dépendances

Passons aux pages intérieures et c’est là le plus important. La plaie de bien des logiciels, ce sont les librairies et les dépendances qui rendent leur installation parfois plus douloureuse que leur utilisation même. Paged.js n’y échappe pas dans la mesure où il a besoin d’un serveur web. L’installation propose de le faire avec des modules node et il faut savoir jouer un peu du terminal pour installer ces derniers. Il faut notamment ledit petit serveur web qui peut s’installer par :

  sudo npm install -g http-server
  http-server (start)

Puis on voit son projet

  http://localhost:8080

Bref : git et npm sont des éléments qui semblent indispensables et demandent une petite culture du développement [edit : si vous avez déjà apache installé sur votre machine pour faire du http://localhost alors c’est inutile]. C’est dommage, car ensuite, coder un livre en html et en css est une chose assez logique et simple.

Julien Taquet propose une version prépackagée un peu différente de paged.js sous la forme d’un boilerplate qu’il a appelé bookstyler et qui repose sur grunt (une autre dépendance à installer ainsi :).

  npm install -g grunt-cli

ensuite on se rend dans le projet, on lance la commande grunt et on peut accéder à son projet dans le navigateur web à cette adresse :

  http://localhost:9000/dist/

Il faut ouvrir un terminal pour installer certaines dépendances et lancer l’utilitaire Grunt.

Pour mon projet, j’ai choisi deux autres dépendances, typographiques celles-là, que sont les polices libres Zilla-Slab de peter Bil’ak et Nikola Djurek de Typotheque et le Chunk Five de Meredith Mandel.

À propos de ces dépendances, polices et scripts, j’insiste (contrairement à ce que dit Julien Tacquet dans son git) sur le fait qu’il est important de ne jamais recourir aux CDN (liens internet pointant ces ressources, collé dans votre code) mais de les télécharger et de les inclure localement dans votre projet. Les CDN posent plein de problèmes imprévisibles dans la chronologie de l’exécution du javascript et sont en général une mauvaise pratique d’un point de vue pragmatique, éthique et sécuritaire.

Paged.js a besoin aussi du navigateur Chromium, malheureusement, notamment pour l’export du PDF final, Firefox ne respectant pas le format de page défini par la CSS lors de cette étape. Il faudra aussi, hélas, passer par Acrobat pour ajouter des traits de coupe et convertir le produit final depuis l’espace RVB vers le noir et blanc (ou le CMJN selon le cas). Il existe peut-être d’autres moyens pour cela, mais je ne les connais pas et suis preneur de vos éventuels conseils.

Avanti, pas-à-pas

Une fois tout cela installé dans le projet, il suffit d’un éditeur de code (n’importe lequel, à votre goût, personnellement j’utilise Sublime text sous linux, mais on peut utiliser un IDE ou un simple éditeur de texte) et de commencer à baliser son contenu en html. Des sections, des titres, des paragraphes. Rien d’autre qu’une structure sémantique du texte. Il est important de comprendre que le html source n’est pas le html rendu dans le navigateur. Les scripts le transforment profondément, mais le fichier source lui-même n’est pas transformé. C’est dans la mémoire du navigateur que le fichier final demeure le temps de l’affichage. On peut ouvrir l’inspecteur pour voir les modifications profondes subies par celui-ci pour faire le livre.

Quelques détails : les notes doivent être insérées en ligne dans le texte au sein d’un élément span. Comme il s’agit d’un livre, il est important de contrôler un peu ses espaces. On peut utiliser des entités unicode pour les différentes espaces, cela fonctionnera si ces espaces sont incluses dans la police de caractères.

espace insécable   ou  
espace fine insécable

Il existe quelques autres signes qui peuvent être encodés ainsi : tirets moyens (– –) et il faut veiller à utiliser de vraies apostrophes et non les chiures de mouche que l’éditeur de code ne manquera pas d’insérer à la place. Après quelques rechercher-remplacer, tout rentre dans l’ordre.

Dans le dossier source, on trouve le html et les feuilles de style découpées en modules spécialisés (body pour les styles du livre, fonts pour les polices, layout pour les formats de page et de marge).

Du côté de la CSS, on peut styler les éléments ou employer des classes. Julien Taquet a séparé la CSS en modules plus spécialisés, ce qui est bien pratique et il suffit d’éditer les préférences. Important, il m’a précisé que paged.js fonctionne mieux avec des tailles de polices en pixels. Attention toutefois, le pixel CSS est beaucoup plus gros qu’un pixel écran et cela ne donne pas des résultats très fins.

La vraie magie de Paged.js, c’est qu’il va faire marcher de bout en bout des classes et propriétés CSS comme

  @page {
    size: 140mm 200mm;
    margin: 1in 2in .5in 2in;
  }

On dispose aussi de différents gabarits de page et de tout un tas de zones dans la marge pour les titres courants, les folios etc. Les détails sont ici en attendant une documentation plus étoffée.

On peut aussi générer facilement du contenu par la CSS, par exemple les folios :

  @page {
    @bottom-left {
      content: counter(page);
    }
  }

Et pour une table des matières toujours fraîche :

  a.tdm::after {
    content: ", page " target-counter(attr(href), page );
  }

Il est possible de contrôler les sauts de pages ainsi :

  h2 {
    break-before: page;
    break-after: avoid;
  }

Il y a plein d’autres petits détails qui permettent facilement de contrôler sa maquette. Ça fonctionne bien.

Les seuls vrais problèmes sont liés à la gestion du texte de lecture lui-même. C’est amusant de constater que c’est la base qui pose le plus de problèmes, quand bien même on peut faire des choses très élaborées visuellement.

La page de titre avec l’inspecteur et les modifications du DOM effectuées par Paged.js.

En effet, la césure et la justification ne sont pas le point fort des navigateurs web. Même si les CSS proposent des propriétés pour les veuves, les orphelines, et la césure. Sous mac, Chromium sait un peu couper les mots, mais sous linux ce n’est pas le cas. On peut utiliser un script hyphenator, mais il faut le raffiner. J’ai eu du mal. En gros, ce script ajoute des traits d’union conditionnels partout dans le texte, et il faut le limiter un peu pour protéger les noms propres, etc.

Enfin, malheureusement, les notes de bas de page ne sont pas encore au point et donnaient trop de bugs de positionnement. J’ai dû y renoncer pour le moment, et opter pour… (malédiction) les notes de fin de section (gasp). Julien Taquet a fait une petite modification du script de gestion des notes pour que cela fonctionne. Je peux dire que je n’ai pas lâché l’affaire facilement et n’ai pas compté mes nuits, mais j’ai fini par lâcher. Il le fallait, car le projet n’était pas qu’un exercice de style, c’était un vrai livre qui devait paraître.

La mise en page telle qu’elle apparaît dans Chromium. Ici une double page de titre avec une gouttière un peu particulière pour tenir compte de la reliure.

Une autre double page de titre avec sa gouttière un peu particulière pour tenir compte de la reliure.

Une double page dans Chromium.

Encore une double page

les notes, renvoyées à la fin malheureusement,

Concluons

Le livre obtenu n’est donc pas parfait, mais au final, le livre est là ! Il paraît la semaine prochaine (j’éditerai ce post pour ajouter quelques images de l’objet imprimé et façonné, j’espère qu’il est beau). Et comme l’annonce le Colophon : « Il n’est jamais trop tôt pour l’émancipation et nous espérons que nos lecteurs nous pardonneront les quelques limitations typographiques que cela implique pour ce premier volume. Suivre cette collection, ce sera suivre les progrès de cette méthode libre de mise en page. » En attendant, je vous propose de télécharger le spécimen pour jauger le résultat.

Télécharger le Spécimen Addiction sur ordonnance au format PDF.

Personnellement je suis emballé par le procédé et prêt à surmonter ses petits défauts pour continuer. Je reconnais qu’il est un peu prématuré d’envisager de basculer toute la production de la maison dedans, mais pour une collection pilote c’est convaincant. En tant que graphiste, je pense que la pratique des logiciels libres est un plus essentiel sur notre pratique et permet également de développer des marchés bâsés sur la durabilité et la confiance. À faire.

le colophon

Les avantages

La clarté et la simplicité du html pour ceux qui aiment le balisage sémantique.
La joie de voir toutes ces belles propriétés CSS dédiées au média paginé fonctionner grâce à l’astuce des développeurs de Paged.js. C’est satisfaisant.
Le plaisir de naviguer dans des planches de pages et de voir sa composition typographique dans la fenêtre du navigateur, fidèle au PDF obtenu.
L’emploi d’outils simples comme éditeur de code, pour décrire clairement ce qu’on veut, plutôt que se perdre dans le cliquodrome aux palettes et fenêtres infinies d’options et des sous-options à cliquer de votre logiciel de PAO habituel.
La libération du livre des solutions de PAO propriétaires bien-sûr.
La version ePub à portée de quelques éditions mineures et rapides.
Un fichier source propre et dénué de mise en forme, pérenne et interopérable.
La possibilité d’ajouter ses petites modifications et modules perso au moyen de Hooks. C’est ça le logiciel libre.
L’engagement des acteurs et des développeurs pour la cause du livre, et leur proximité.

Les inconvénients

Des petits soucis d’ergonomie. Par exemple, on ne peut atteindre facilement une page, utiliser le hash dans l’adresse serait bien pratique pour ce faire. En revanche, on peut tout à fait ne compiler qu’une partie du livre, pour gagner du temps, il suffit de commenter les autres sections dans le html.
Une mise en place un peu lourde si vous n’avez pas un serveur web actif sur votre machine, avec des dépendances. Cela nécessite pour le moment un peu de culture du développement (ne serait-ce que Git), mais l’équipe travaille à simplifier ça.
Pas de notes de bas de page pour le moment, trop instable et imprévisible, mais l’équipe y travaille. Souhaitons qu’ils surmontent rapidement toutes les difficultés que cela pose. Car c’est loin d’être simple.
Un manque d’intelligence linguistique (C&J – césure & justification – du français) des outils logiciels, qui n’est pas du tout évident à contourner. Ceci dit, sur certains points, on a déja dépassé InDesign qui est assez crétin sur certains détails.
Au final, on a bien un PDF, mais il n’est pas encore tout à fait fini : c’est un fichier en RVB qu’il faut penser à convertir en noir ou en CMJN, ce qui demande une version professionnelle d’Acrobat, d’autant plus qu’il faut ajouter ses traits de coupe pour l’imprimeur. Bon après ce n’est pas un drame absolu, et je sais bien que le fichier final passera encore entre les mains de logiciels privateurs chez l’imprimeur, par exemple celui du RIP, donc sachons déjà être content de ce qu’on a.

Mais tout cela est en plein développement et je suppose que cela va beaucoup évoluer dans les mois qui viennent. Un grand bravo pour tout le travail accompli dans pagedjs, et un grand merci aux développeurs pour le soutien dans les moments de doute :-)

Maintenant, on peut feuilleter le livre, imprimé, et le mieux est encore de se procurer un exemplaire !

Addictions sur Ordonnance, la crise des antidouleurs. Patrick Radden keefe – C&F éditions, 16 € – ISBN 978- 2-915825-90-9 – (Collection interventions).

Le livre en volume, et dans toutes les bonnes librairies ;-)

Polylogue

Le blog un peu ensommeillé de Nicolas Taffin.