Ét.Nadji.fr/

Du code, des mots, des livres.

Scribus, la PAO et les mathématiques

11/04/2021 à 20h

En 2020, je publiais une première version d’une librairie Python destinée à lire, comprendre et manipuler le format de fichier de Scribus (SLA). Et une nouvelle version peu de temps après.

En codant cette librairie, je me suis rendu compte que ce format encode une story (soit un texte unique divisible en autant de cadres de texte que l’on souhaite) une seule fois, dans le premier de cadre de texte où il est employé, ce qui est normal. Le format indique ensuite dans les autres cadres texte liés à une story la référence de cette dernière. D’accord. Mais pas du tout le texte reprend dans ces cadres liés.

Capture d’écran de Scribus
Une story « liée » dans trois cadres de texte, de haut en bas et de gauche à droite.
Code

<!-- J’ai (beaucoup) raccourci les attributs des PAGEOBJECT -->

<!-- Le premier cadre de texte -->
<PAGEOBJECT ItemID="898988708" PTYPE="4" NEXTITEM="921852452" BACKITEM="-1">
  <StoryText>
      <DefaultStyle/>
      <ITEXT CH="Commençons par la considération des choses les plus communes, 
et que nous croyons comprendre le plus distinctement, à savoir les
corps que nous touchons et que nous voyons. Je n’entends pas parler
des corps en général, car ces notions générales sont d’ordinaire plus
confuses, mais de quelqu’un en particulier. Prenons pour exemple ce
morceau de cire qui vient d’être tiré de la ruche : il n’a pas encore perdu
la douceur du miel qu’il contenait, il retient encore quelque chose de
l’odeur des fleurs dont il a été recueilli; sa couleur, sa figure, sa grandeur,
sont apparentes; il est dur, il est froid, on le touche, et si vous le frappez,
il rendra quelque son."
/> <trail/> </StoryText> </PAGEOBJECT> <!-- Les cadres de textes liés --> <PAGEOBJECT ItemID="921852452" PTYPE="4" NEXTITEM="911509924" BACKITEM="898988708"/> <PAGEOBJECT ItemID="911509924" PTYPE="4" NEXTITEM="-1" BACKITEM="921852452"/>

Ce qui signifie que c’est Scribus qui détermine où le texte reprend chaque cadre de texte lié, en analysant les informations du fichier (grilles, styles employés, etc). Et qu’il n’y a donc aucun moyen de déterminer qu’un texte est en excès (est trop long malgré tous ses cadres liés) simplement en lisant le fichier.

Qu’un format soit relativement stupide, et les logiciels susceptibles de le lire soient « intelligents », c’est courant, et même un principe d’Internet – les serveurs sont largement moins complexes que les navigateurs. Mais moi, eh bien, ça m’arrangeait pas. Car si je ne pouvais pas déterminer qu’un texte était en excès « juste » en lisant le fichier dans son idiome bien à lui, je ne pouvais pas créer une fonction qui permettrait au développeur d’insérer un texte dans un premier cadre, et au besoin, de couler automatiquement le reste du texte dans des cadres liés.

C’est dans ce genre de moments que tous les efforts humains nécessaires pour faire de la PAO, de la composition de documents de manière simple, se rappellent à vous.

On ne mesure pas (assez) à quel point la mise en page et la typographie sont des cauchemars mathématiques – quoique se basant sur de la géométrie plus ou moins basique. Comment ce qu’on pourrait pourtant résumer à « faire rentrer des rectangles dans d’autres rectangles de façon élégante » est une tâche complexe que les logiciels nous simplifient heureusement.

«  CSS est victime de ce genre de dédain parce qu’il permet de régler ce genre de question, dans une mise en page fluide qui plus est, mais sans trop laisser entendre la complexité que ça représente. En plus d’être « un peu bizarre ».  »

Déterminer si un texte est en excès, ce n’est pas simple du tout. Si un texte était composé en monospaces, avec uniquement des espaces simples et un seul corps, on pourrait s’en tirer sans trop de problèmes, et encore.

Mais dans les faits, la plupart des textes sont bien plus complexes. Il peut y avoir plusieurs corps, une grille de référence à prendre en compte, plusieurs polices ; dans un texte composé correctement en français, il y a plusieurs types d’espaces; il y a des alignements, des paragraphes, etc. Il y a la question des césures, automatiques et/ou manuelles. Autant de variables qui rendent ces calculs compliqués.

Je suppose que plutôt que de calculer d’emblée la « taille » totale d’une story, les logiciels de PAO remplissent bloc par bloc les cadres de texte, et s’il reste des éléments non-traités, changent de cadre de texte où travailler. Cela simplifie le calcul, mais pose d’autres problèmes (notamment pour faire des césures).

Remarque:
Dans le cas de Scribus, il « suffit » sans doute de vérifier si le tag du dernier élément traité est différent de trail, sachant que trail n’a pas de taille et indique que la story est terminée.

Une fois qu’on a pris conscience de cette complexité, eh bien on râle toujours autant, parce que si la composition d’un texte demeure un art, les logiciels de PAO, les systèmes de composition à la LATEX demeurent des outils. Mais on râle au moins pour de meilleures raisons, et moins fort quand le placement d’une figure sous LATEX est peu naturel.

«  Mais oui, un overfull hbox badness machinchose, ça casse quand même bien les gonades.  »

Commentaires

Pour commenter ce billet, envoyez un mail sur etnadji (at) eml.cc, ou créez-vous votre blog.