Se remettre à la page

Je me suis rendu compte en cours de rédaction que ce que j’avais imaginé être un billet court avec quelques réflexions personnelles commençait à être long. Il y aura donc plusieurs billets et celui-ci est devient l’introduction d’une série.

Depuis deux semaines et demi, presque trois en fait, je participe à un sprint numérique pour réaliser le plus de modèles de mise en pages possible pour réaliser des livres depuis un source au format HTML[1] (confer le billet ‌mettre en page(djs). Il est nécessaire pour moi — d’autant plus nécessaire que mon nez est bien pris, ma respiration pénible (et je ne vous dit pas pour ma famille, rapport aux ronflements) et mon sommeil pour le moins décousu — de faire une pause et compiler mes premières impressions.

Cependant, avant cela je souhaiterais vous présenter le contexte global dans lequel ce sprint s’inscrit.

Coko foundation : Editoria, paged.js et Open Education Network

Ce projet est, une des raisons pour laquelle je l’apprécie, sous le signe du libre et de l’ouvert :

le tout sous l’égide de la fondation Coko.

En résumé : il s’agit de participer à un programme de partage des savoirs opposé au modèle d’Elsevier & Co.

Comment cela s’articule ?

  1. Le contenu de l’ouvrage est saisi (ou importé) puis organisé dans Editoria
  2. Une fois le projet de livre finalisé, ce même logiciel produit un fichier HTML (comportant les liens vers les illustrations) dont le balisage est adapté au type de publication
  3. En fonction de ce type, un éventail de gabarits de mise en pages est proposé
  4. C’est après ce choix qu’Editoria utilise la bibliothèque paged.js pour effectuer une conversion en fichier PDF (avec traits de coupe et fonds perdus) selon le modèle choisi.

Alice, Kiara et moi-même intervenons donc sur les éléments permettant à paged.js de réaliser la transformation selon un modèle donné : à savoir des feuilles de style CSS[3] suivant les recommendations du W3C pour les médias paginés avec quelques extrapolations et anticipations permises par paged.js.

Il est aussi possible d’ajouter des scripts pour retravailler la structure du document en cas de besoin.

Qu’est-il possible de faire ?

Je répondrais bien « tout » à cette question mais c’est sans doute un ambitieux et surtout trop tôt. L’objectif second de ce sprint est l’expérimentation des possibles et la mesure des obstacles rencontrés par les designers ou graphistes dans la réalisation de leurs idées.

Je peux cependant vous dire que l’essentiel est présent : la gestion des marges, les sauts de pages (avec règles d’enchaînement et de coupure), les colonnes, les notes de pied de page, la possibilité de définir des types de pages en accord avec le découpage éditorial du livres, et cætera.

À ceci s’ajoute toutes les possibilités graphiques et typographiques permises par les sélecteurs CSS de niveau 3 et les propriétés CSS disponibles.

De fait, la difficulté n’est pas dans les éventuelles limites de ces outils web. Elle est due au principe même de transformation automatisée d’un objet éditorial en une suite de pages mises en forme. Ici les ajustements après la mise en page ne font pas partie du processus. Il n’est pas possible de faire des retouches page par page ou paragraphe par paragraphe pour modifier tel interlettrage ou forcer tel retour à la ligne dans le but d’améliorer un gris typographique ou éviter un changement de page. Non, tout ces cas de figures doivent être envisagés, anticipés. C’est ce qui est à la fois passionnant — concevoir des mises en pages intéressantes et « résistantes » — autant que frustrant car, en dehors du livre test servant de support pour la création initiale d’un gabarit, le ou la graphiste aura peu de visibilité et encore moins de possibilités de retouches sur les livres créés !

Voilà pour la présentation du projet et de ses enjeux. Le prochain article sera sur paged.js elle-même[4] et sur comment l’aborder.

Rédigé à toulouges en juin 2022.