Curseurs sans sou(c/r)is: Jour 1
Je me lance, pour 4 semaines de stage chez Tactic, dans une petite mission à visée anti-souris. C'est-à-dire: essayer d'adapter la revue Curseurs de Tactic depuis un document Scribus à la mise en page par du web to print. Bon, Paged.js spécifiquement. Je ne connais pas assez les autres outils. Ça reviendrait à dire que pour mettre en page la revue, on n'utilisera pas un éditeur WYSIWYG, même si on aura un preview du résultat après chaque changement, et donc on n'utilisera à priori pas autant sa souris. Curseurs sans souris.
Pour ce qu'il en est de Curseurs sans soucis, ça reste à voir. :)
Done:
J'ai fait les mesures anatomiques de la mise en page de Curseurs avec Scribus. Les marges, interlignes, tailles de fonte, espacement, gouttière, et typos sont bien notées. C'est assez médical comme procédure, on a l'impression de prendre un scalpel et disséquer un bout de papier. Mais tout celà démystifie un peu la mise en page d'un journal. Ben ouais!
J'ai aussi établi un plan d'attaque. Faut pas se mentir, ça va être difficile et ça demandera de la patience. Le voici:
README.md
--------
TODO Pour ces 4 semaines de stage:
Grande mission: tester web2print (pagedjs) pour curseurs, quelques doubles-pages
Découpe:
[x] Mesurer toutes les marges, tailles, fontes, etc
[x] Créer un document html calqué sur les propriétés de page
[] Créer le contenu des marges (et voir comment organiser ça pour le choper depuis du front-matter?)
[] Créer des classes css spécifiques à chaque type de contenu textuel
[] Créer le hook de Lionel pour les espaces blancs des pouces
[] Intégrer Showdown ou Parsedown pour parser du Markdown vers HTML
[] Ajouter un parseur custom pour les classes de contenu qui n'existent pas en Markdown
- par exemple des descriptions d'articles à côté du titre, classe pour le nom d'auteurice, carrés de texte non-flowing
[] Essayer de voir comment faire hook pour positionner une image non-flowing sur une page
J'ai aussi commencé à tenter les marges et le style typographique à répliquer:
petite suggestion: faites toujours des border:0.5px avec une couleur pétante pour voir où sont en fait les éléménts. vous serez surpris.es
La mise en page de Curseurs est assez compliquée, et avec Scribus elle devient franchement dure à garder en tête. Plusieurs types / classes d'éléments se chevauchent, prenant la même fonte mais avec une différente couleur, ou une différente taille, et même à l'intérieur d'un même paragraphe, deux fontes avec des tailles différentes les rendant visuellement égales. Tout ça contribue à un résultat franchement superbe, et on voit le travail fourni dans cette tâche complexe. D'autant plus qu'ielles sont passé.e.s par Scribus! L'enfer n'a jamais été aussi beau à feuilleter.
Comment refaire ça avec PagedJS? Je ne sais pas, mais ça sera accompagné de quelques "JULIIIIIIE? COMMENT ON FAIT X? JULIEEEN TU SAIS SI Y EST POSSIBLE?" (Julie Blanc et Julien Taquet sont parmi les maintainers du projet)
Les transformations des contenus des marges (@page margin boxes) sont super difficiles à faire (bien). Je me suis amusé avec la numérotation de page, j'ai réussi à faire presque la même mise en page que sur l'original. Mais je comptais sur ça pour créer un margin-bottom
jaune (la ligne de marge supérieure dans Curseurs.) Maintenant que le contenu a une rotation appliquée, son border-bottom sera transformé lui aussi. Faudra compter sur une deuxième feuille de style post-PagedJS qui visera les classes générées par PagedJS. .pagedjs_page_content
est la classe qui représente l'intérieur de la page. On lui appliquera un style de bordure supérieure à elle plutôt qu'aux boites de marges.
C'est tout pour day 1!
Curseurs sans sou(r/c)is: Day 2:
Essai de maintenir la position du scroll quand on recharge la page.
Comme ça si on change une page précise on n'a pas à rescroller vers elle. Pratique comme InDesign.
Pas si facile que ça. Il s'agit d'enregistrer la position du scroll lors de l'unload dans le localStorage. Et puis de la rechoper quand tout le document est chargé. Mais juste comme ça, ça ne fait rien. localStorage
a bien enregistré la valeur du scroll, mais Chrome/ium est tellement rapide (visiblement) qu'il charge cette position avant même lui-même de dire à la page de scroller vers le haut. Du coup à chaque fois il charge ça et il fait scroller vers le haut après.
Solution: setTimeout(function(){scroll etc}, 100);
. 100ms. Peut être moins, mais sur mon ordi ça marche pas avant les 200ms. Il est un peu vieux pépère. A ajuster selon l'utilisateur.
En tout cas ça fonctionne!
Progrès du setup initial de la mise en page
J'ai repris l'article "le cumul des obstacles..." page 8 du N°2. Il tient parfaitement sur une double page, avec une insère d'image en non-flow entre deux colonnes, deux sections, des notes de bas de page et des notes d'articles, et une image en fin. Je me lance le défi de recréer cette double page de la manière la plus fidèle.
Refaire les marges
J'ai changé les marges observées sur Scribus dans les propriétés du document. Elles étaient à 15mm pour les marges intérieures.
Le petit corps du texte courant (celui de l'article, en 3 colonnes) est un peu plus éloigné des bords, pour permettre la lecture même quand, face à la tempête de plis, replis, feuilletage, et jetées dans un sac ou sur une table, les bords se froissent ou les feuilles se chevauchent. Ce n'est pas le cas pour les gros éléments comme les titres. Bien pensé.
Mais! ça demande une restructuration. Je ne veux pas m'amuser à faire 36 règles de calcul pour positionner mes boîtes de texte et leurs marges. Le texte courant est le truc le plus important. Les marges se plieront à son règne. Les autres éléments n'ont qu'à bien se tenir (avec des margin-left, position: relative,
etc.)
Grille typographique (baseline et hauteurs de ligne)
Là c'est plus compliqué. Sur un PAO graphique on crée la ligne de base et on clique sur "snap to baseline grid" pour soumettre la typo à un régime ordonné et rangé, un peu comme les files deux par deux en primaire. Comme je suis anarchiste, je préfère ne rien leur ordonner, mais plutôt de leur dire comment le faire. On sait tous que les navigateurs respectent nos règles seulement si ils ont vraiment envie. :) Donc il faut le faire avec subtilité et douceur, sinon le parseur nous crache à la figure
Il faut:
- Créer une hauteur de ligne de base . Ça sera la hauteur de ligne de notre texte courant. Toujours partir du gris de texte initial et ensuite choisir les tailles et espacements des éléments. Ceci sera notre unité principale.
- Choisir la hauteur (calquée sur la taille de caractère) de ligne des éléments de type titre, sous-titre etc.
- Calculer les marges de tous les éléments du document en respectant le fait qu'elles doivent être un multiple de notre unité principale.
C'est pas une pratique hyper répandue dans le web design. Mais pour les pages imprimées, pour les colonnes, etc, c'est hyper important pour ne pas se retrouver avec des lignes de texte qui ne sont pas synchro.
Il faut que je trouve une meilleure façon de le faire qui utilise des variables et qui calcule tout de base
Pour l'instant, 30 Avril 2024, 13h38, voila à quoi ça ressemble:
Ces trucs bleus, c'est les lignes de la grille. Elles ne seront pas imprimées. Elles nous aident par contre.
Bold et Italic
A faire attention lorsqu'on a du texte en bold ou italique <strong>
ou <em>
: la hauteur des glyphes est supérieure à celle dans la fonte Regular. Forcer une line-height relative à la fonte (12pt
dans ce cas) ne change rien: la fonte est plus grande, la line-height sera plus grande.
La différence n'est pas grande, mais assez importante pour se faire remarquer quand on a plusieurs colonnes sur une page. Les lignes de texte se décalent après un bold ou italic.
Deux solutions:
- Refaire toute la ligne de base en pixels ou en millimètres pour avoir des unités indépendantes des tailles de la fonte. -> pas encore testé, pas envie, trop de bidouillage. Peut s'automatiser.
- Se servir du preview de la baseline dans l'interface de PagedJS pour choisir manuellemet la taille des insères en bold ou italic. Sachant qu'il s'agit de deux styles, potentiellement un troisième bold italic, c'est peu de travail à faire par rapport au bénéfice d'avoir une belle grille de texte.
Personnellement, j'ai choisi 11pt pour les insères strong et em par rapport à 12pt pour la variante régulière. Jusqu'à preuve du contraire, sur mon ordi ça marche bien. :)
Titres des sections dans l'article
Il y a dans l'article que je retravaille un seul titre de section:
Ce que le confinement nous a appris sur l'École
Ce titre est en bold
, en typo différente ("Redaction 10"
) et avec une taille différente (12pt
). Pour qu'il ne pousse pas le texte en dessous, dans quel cas on casse la grille typo, Il faut lui choisir une hauteur de ligne proportionnelle à la hauteur de ligne du texte courant. Un multiple entier est préférable.
Cependant, si on lui donne une hauteur de ligne de 1x (x étant hauteur de ligne courante), si le titre a une longueur de plusieurs lignes, il est trop rapproché. (ben ouais en corps 12). Si on fait 2x, il se retrouve un poil trop éloigné. Comment faire?
Pour l'instant:
- sa marge du haut est de 2x
- sa marge du bas est de 1x
Pour respecter le rythme des hauteurs de ligne, il faut respecter l'équation suivante pour les titres trop grands pour une ligne, trop petits pour deux lignes:
(hauteur de ligne × nombre de lignes) + marge du haut + marge du bas = (n × x) où x est la hauteur de ligne du texte courant, et n est un nombre entier
Sachant qu'on veut garder des marges supérieure et inférieure optiquement constantes. Donc un calcul qui déterminerait la marge en fonction des hauteurs de ligne est à faire avec attention pour ne pas trop déséquilibrer ça.
Si on a deux lignes par exemple, on peut se permettre de faire une hauteur de ligne de 1,5x, ce qui donnera en tout 3x, 3 est bien un nombre entier. Mais si le prochain titre est à une ou trois lignes, ou cinq, bonne chance pour équilibrer ça, sachant que CSS ne calcule pas le nombre de lignes.
Possibilité: faire des classes pour les titres qui apparaissent en nombre de lignes pair ou impair
A moi de faire ça prochainement. Hihi.
J'ai un seul titre de section, donc c'est facile. Heureusement, quand j'aurai intégré Showdown ou Parsedown, les headings H1, H2, H3, H4, H5, H6 auront des ID générés selon le contenu textuel, ce qui permettra de les viser plus facilement et de faire du calcul (désolé) individuel pour chaque petit titre.
C'est un peu compliqué, mais gardons ça en tête:
(hauteur de ligne × nombre de lignes) + marge du haut + marge du bas = (n × x) où x est la hauteur de ligne du texte courant, et n est un nombre entier
DONC SI:
( (hauteur de ligne × nombre de lignes) + marge du haut + marge du bas ) ÷ x
est un nombre entier, on est bon!
La preuve:
la hauteur de ligne ici est 12 x (2.4 / 2) = 14.4 mon nombre de lignes est 2 (je le sais pcq je le vois) ma marge inférieure est de 12 x 1 = 12 ma marge supérieure est 12 x 1.6 = 19.2
((14.4 × 2 ) + 19.2 + 12) ÷ 12
= (28.8 + 19.2 + 12) ÷ 12
= (48 + 12) ÷ 12
= 60 ÷ 12
= 5 qui est un nombre entier! on est bon! On connait aussi le nombre de lignes que prendra le bloc de titre de section avec ses marges, cinq! Génial.
Il faut garder en tête qu'un bon espacement (marges) pour ces titres, c'est environ 1.5x en marge supérieure pour 1x en marge inférieure. Donc ne pas avoir des valeurs de marge trop éloignées de ça, et surtout la supérieure est plus grande que l'inférieure. C'est confus je sais.
C'est tout pour day 2!
Curseurs sans sou(r/c)is: Jour 3
2 Mai 2024
Créer une machine de ~guerre~ paix
Aujourd'hui, il est peut-être temps d'installer un Parser pour Markdown vers HTML. Ceci rendrait l'insertion des articles bien plus facile, car le balisage en HTML prend plus de temps. A moins qu'on veuille se casser la tête à écrire du LaTeX.
J'ai pensé à deux options que j'ai déjà utilisé pour convertir Markdown en HTML.
- Showdown.js -- un parser en JavaScript, le plus connu, que je sache. Il fait les opérations côté client, ce qui veut dire que l'ordinateur qui souhaite voir le résultat a la charge des tâches.
- Parsedown -- un parser PHP, plus rapide que Markdown PHP. Il fait la conversion côté serveur, donc le contenu est généré avant d'être envoyé au client en HTML.
Dans notre cas, la plupart du temps pour Paged.js on travaille sur un ordinateur qui est à la fois serveur et client. Dans ce cas, la différence de chargement est négligeable, car un même processeur fera les deux types d'opération.
Mais on a déjà une partie du programme qui tourne en JS, donc côté client: Paged.js, bah ouais... Et si... on partageait la tâche entre JS et PHP?
Enfin non, Paged.js et Showdown peuvent tourner sur un serveur, à condition qu'il soit un serveur Node.js. Et un serveur Node.js, c'est plus chiant à installer que de taper php -S
ou de lancer un petit serveur HTML rapide. Donc la plupart du temps on va utiliser ces deux programmes côté client.
- PHP, et donc le serveur qu'on lance sur l'ordi, sera responsable pour le chargement du contenu. C'est en PHP qu'on chargera le fichier Markdown et qu'on enverra du HTML. On pourra en une ou deux lignes changer les fichiers qu'on charge, et en charger plusieurs. Mais il faut accès au serveur
- JavaScript, et donc le client, aura la responsabilité de faire la découpe et la mise en page du contenu. En plus de Paged.js, on aura probablement besoin d'un deuxième passage par JS (pour régler certains trucs (parfois (ça aide))).
- En plus, avec cette séparation on pourra mettre les documents sur un serveur (un vrai, plus rapide) et collaborer par des pads ou des documents partagés. Chacun sur son ordi chargera le même contenu exactement, et la mise en page sera faite par l'ordinateur qui accède au serveur.
- En plus en plus on peut intégrêr d'autres trucs en PHP comme JoliTypo qui règle les erreurs microtypographiques (faut pas oublier qu'à la base je suis en design graphique, même si je fais ma guerre contre les conventions du Code typographique à l'usage de la presse).
Donc, récap:
- On charge avec Parsedown.
- On modifie avec JoliTypo.
- On met en page avec Paged.js.
- On règle le contenu généré par Paged.js s'il faut.
Parsedown et ses problèmes
Parsedown est super! Sauf qu'il ne lit pas le Markdown Extra. Alors que c'est super utile!
Avec du Markdown Extra, on peut associer des classes aux lignes qu'on écrit. On peut aussi, et c'est là la force de cet outil, créer des éléments HTML dans lesquels on écrit en Markdown. Mais c'est quoi la différence? Bon:
Markdown normal:
Ceci est un *paragraphe* en Markdown.
<article>
Ceci est une balise article qui n'est qu'en HTML. Le formatage à l'intérieur est en HTML et donc le *Markdown* **ne marche pas**. La preuve, pas de bold et italique.
</article>
-> Parsedown ->
Ceci est un paragraphe en Markdown.
\
Ceci est une balise article qui n'est qu'en HTML. Le formatage à l'intérieur est en HTML et donc le *Markdown \*ne marche pas**. \
Markdown Extra:
Ceci est un *paragraphe* en Markdown.
<article>
Ceci est une balise article qui n'est qu'en HTML. Le formatage à l'intérieur est en HTML et donc le *Markdown* **ne marche pas**. La preuve, pas de bold et italique.
</article>
<article markdown="1">
Ceci est une balise article qui a le **parsing markdown** *activé* donc le **bold** et *italique* fonctionneront.
</article>
-> ParsedownExtra ->
Ceci est un paragraphe en Markdown.
\
Ceci est une balise article qui n'est qu'en HTML. Le formatage à l'intérieur est en HTML et donc le *Markdown \*ne marche pas**. \ \
Ceci est une balise article qui a le parsing markdown activé donc le bold et italique fonctionneront. \
Ça nous permet d'englober du contenu formaté au Markdown dans des balises HTML Pour mieux regrouper certaines sections de contenu. On peut alors utiliser des règles CSS pour l'élément englobant.
Moi, j'utiliserai ça pour faire une balise article qui englobe tous les paragraphes d'un article, pour faire une mise en page en 3 colonnes pour l'article entier et non pas pour les paragraphes individuels, qui eux se suivront dans ces trois colonnes au lieu d'avoir trois colonnes chacun.
Cette fonctionnalité existe par défaut dans Showdown, ce qui le rend sympa aussi.
Et c'est bon! J'ai installé Parsedown ET Parsedown Extra (qui dépend du premier) et j'ai lancé un texte en Markdown dans le HTML. Tout fonctionne.
Jusqu'ici tout va bien ... Jusqu'ici tout va bien ... Jusqu'ici tout va bien ... Mais l'important c'est pas la chute, c'est atterrissage.
Beat the gris de texte with the cursor wedge
PROBLEME!!! PROBLEME!!! PROBLEME MONSIEUR LISSIZKY!!!
Une des caractéristiques les plus intéressantes de Curseurs, d'un point de vue typographique, ce sont les triangles sur les marges extérieures. Comme c'est une publication format journal, le papier est... assez grand et pas relié. Et comme il est assez grand, on le tient avec deux mains. Et comme les feuilles sont volantes, on va tenir plus solidement le journal, donc utiliser plus de place pour nos pouces. Super idée des typographes, qui ont intégré ces triangles d'espace blanc à mi-hauteur de la page où les pouces peuvent se reposer sans enfreindre la lecture. C'est super. Mais...
Quand on passe de Scribus à Paged.js, ce petit triangle doit être un élément généré dans chaque page, avec des propriétés qui permettent au texte de contourner sa forme, et non pas d'être poussés de manière égale vers la marge intérieure le long de la page.
Avec Lionel Maes, on a pensé à ça et on a créé un hook JavaScript qui insère dans le template de base une balise <span>
. Puis on la stylise avec du CSS par la propriété shape-outside
. Et ça marche!... quand on a une seule colonne de texte...
La gestion des colonnes de texte est visiblement assez obscure et difficile. Chez Curseurs, on en a trois. 3! III! Et donc quand on applique ce truc ben... ça marche pas. Mais pourquooooiiii ça marche pôôôôôs?! -- Je sais pas. En tout cas ça décale tout le texte, ça pousse sa marge extérieure à l'extrème. On se retrouve avec trois colonnes qui se chevauchent, de 2 caractères chacune!
Pics or it didn't happen:
Solution/s/?
Embêtant. Ha ouais. Je pourrais m'en passer, faire une marge un poil plus large en extérieur et laisser tout ça aller car visiblement shape-outside
ne s'entend pas bien avec column-count
. Mais ça serait enlever un bout d'âme graphique qui donne à la revue son charme. Bref, j'aimerais passer ça en Plan B.
Sinon, ce qu'on pourrait faire, c'est faire un autre hook, une autre injection dans le fonctionnement de Paged.js. Cette fois-ci, pas dans le Template, mais dans le Chunker, entité encore obscure, qui va s'occuper de découper le contenu, plus grand que la taille d'une page, en plusieurs pages, en respectant donc la taille de la page entre les marges.
Si Paged.js mesure la taille de la page et du contenu pour le découper alors je pourrais faire le même en prenant en compte le nombre de colonnes et la gouttière et donc je pourrais afficher trois colonnes de texte qui se suivent et puis je pourrais ordonner à la colonne le plus à l'extérieur de suivre les contours de la forme injectée.
A faire... mais je ne connais pas du tout assez Paged.js et ses fonctionnalités.
Curseurs Jour 4
En direct de la chute libre
On aura rencontré un problème au Jour 3. On s’est aperçu que le code créé avec Lionel (celui qui s’insère dans le fonctionnement de paged.js pour modifier le template de base) ne fonctionne que quand nous avons un élément à une colonne (à savoir que column-count
< 2
).
On a (j’ai) crié à l’aide dans le groupe de Pre Post Print, et merci Julien Taquet pour la réponse rapide!
On ne savait pas pourquoi. Aujourd’hui, au moins, je peux donner la moitié de réponse.
Cette propriété de multi-colonne est particulière. Elle prend un élément englobant et rend tous ses éléments intérieurs soumis au flux du nombre de colonnes choisies, avec si souhaitée une largeur minimale de colonne. Ainsi-faisant, les quelques colonnes sont ensemble considérées un “tout”, un entier à ne pas déranger. Si on veut leur donner une forme autre que celle de base (rectangulaire), il faut le faire par l’intérieur et non pas du dehors. C’est un peu comme un château fort, et c’est pas en bombardant avec des trébuchets ou des catapultes ses murs extérieurs qu’on peut changer la disposition de sa cour intérieure. Au contraire, ça casse juste les murs et tout se brise.
Solution? Cheval de Troie.
Enfin, c’est pas une superbe solution. Mais Julien Taquet avait raison. Je ne l’avais juste pas compris.
Il m’avait dit d’insérer au sein de l’élément colon?nifié? un élément qui aura une forme avec shape-outside
, à l’exact endroit où j’en ai besoin. Lui formera le flux du texte à l’intérieur d’une (1) colonne.
<div class="column-container"> <!-- Le truc avec la propriété column-count -->
<p>Element dans une colonne</p>
<div class="shape-element"> <!-- L'élement shape-outside -->
<!-- Content here will be shaped and text will flow around it -->
</div>
<p>Encore un élement qui obéit au flux de colonne.</p>
</div>
Les problèmes avec cette solution
Le problème avec cette solution-ci, c’est que, premièrement, cet élément-formeur ne peut pas excéder la taille d’une colonne. Si on s’amuse à le forcer, en lui donnant une largeur de 150% par exemple, la largeur des colonnes de texte qui sont en contact avec (éléments avant et après) va changer pour augmenter, et se superposer aux colonnes adjacentes. Donc, il faut se contenter qu’un élément=une largeur de colonne, un élement impactera une seule colonne.
Ça, pour les espaces blancs des pouces, ça ne nous dérange pas trop encore. En revanche, ça nous perturbera dans le futur, quand il s’agira d’intercaler des images entre les colonnes et donc de donner forme à deux colonnes en même temps.
Si on (je) trouvai(t/s) une façon d’automatiser l’injection d’un élément-formeur au bon endroit selon des calculs un peu matheux j’imagine, il serait à priori possible d’injécter un élément en générant la moitié gauche dans la partie droite de la colonne gauche, et la moitié droite dans la partie gauche de la colonne droite. Ensemble, ça ressemblera à un tout, en soi ce seront deux éléments distincts. Puis on pourra fixer une image par dessus, une fois qu’on a dégagé le texte.
Mais bon j’ai pas encore les capacités. Quelqu’un d’autre?
L’autre problème, c’est que Curseurs a toujours ces éléments à la même hauteur. Ils ne dépendent pas du flux de texte. Mais quand il faut les injecter au sein du texte, ça devient un travail long manuel, et c’est la dernière touche à mettre dans l’enchaînement éditorial. Car si on décide qu’un article est trop long ou pas assez, si on aperçoit une erreur après la mise en page de ces éléments, il faut après la correction re-positionner ces éléments exactement au bon endroit dans le texte. Et le faire un par un, en partant de la première page vers la dernière, sans sauter d’éléments. Car à chaque fois qu’on en insère un, le texte qui suit sera affecté et décalé. Et les corrections microtypographiques doivent suivre ce rythme aussi, sinon elles seront aussi décalées. À moins qu’on jette les convetions typographiques françaises par la fenêtre, et je suis le premier partant pour ça.
C’est pas un travail terriblement compliqué ou dur, mais c’est terriblement emmerdant pardon.
Mission: trouver une façon d’automatiser par du javascript au moment du chunker la création de cet élément formeur injecté au bon endroit.
EN TOUT CAS POUR LE MOMENT VOICI COMMENT LES POSITIONNER:
- Trouver la ligne après laquelle ce triangle doit apparaître
- Voir s’il y a césure ou pas. Si oui:
- Créer la césure à l’endroit précis en insérant une césure discrète (
­
pour soft hyphen). Si cela n’est pas fait l’élémen apparaîtra à la ligne suivante. - Insérer l’élement
<span>
avec classepoucedroit
oupoucegauche
selon le coté duquel il devrait apparaître, juste après la césure.
- Créer la césure à l’endroit précis en insérant une césure discrète (
- Sinon, Insérer l’élement
<span>
avec classepoucedroit
oupoucegauche
selon le coté duquel il devrait apparaître, juste après la césure. - Vérifier si l’élément apparaît bien là où on le veut. Sinon, expérimenter sur les mots autour avec espace,
et d’autres entités pour arriver à la forme souhaitée.
L’élement-pouce lui-même a deux versions du style:
gauche:
display: block;
float: left;
width: 50%;
height: 55mm; /* approx /
shape-outside: polygon(0 0, 0% 100%, 100% 0);
clip-path: polygon(0 0, 0% 100%, 100% 0);
background: transparent; /* changer pour le voir */
droite:
display: block;
float: right;
width: 50%;
height: 60mm;
shape-outside: polygon(0 0, 100% 100%, 100% 0); /*inversé*/
clip-path: polygon(0 0, 100% 100%, 100% 0);
background: transparent; /* changer pour le voir */
Pour l’instant, nous voilà:
On est à peu près à quelque chose qui ressemble à
Pas maaaaaal? Eh ben c’est pas fini.
J’ai rajouté les éléments des marges, et on y est à peu près (regardez pas trop encore le trait brun). J’ai aussi baissé la hauteur de début de texte à la page de droite comme sur l’original. avec
@page:nth(3) {
article {
margin-top: calc(20 * 12pt) !important;
}
}
Au lieu de donner une marge supérieure exacte, j’ai multiplié le nombre de lignes duquel je veux descendre par la hauteur de ligne. Comme ça on est sûr de bien se caler sur la baseline. Pour l’instant, et pour finir aujourd’hui:
Curseurs sans sou(r/c)is: Day 5
Rien à signaler aujourd’hui. Je fais les détails microtypographiques pour arriver à la mise en page la plus proche de ce que je vois dans l’original. Italiques, bold, etc.
J’ai rajouté des blocs pour repousser le texte là où il y a des images. Je les ai coloriés en rouge pour les identifier plus facilement. Il faut les peaufiner.
J’ai rajouté un style pour le nom de l’auteur.
Il me reste seulement un carré de texte à placer, on verra ce que ça donne.
Pour l’instant:
Curseurs sans sou(r/c)is: Day 7
L’image c’est la mort
Je reprends là le titre d’une des sections de mon mémoire, tant ma situation face aux images ne semble jamais montrer autre que moquerie envers ma personne. Je le prends personnellement à ce point. En bref, la gestion des images est compliquée, visiblement pour ce type de mise en page.
Flicage typographique et pixels vagabonds
Vous souvenez-vous de la règle absolue de la grille de base typographique? Avoir une unité à respecter, correspondant à la hauteur de ligne du texte courant. Et tant mieux que j’ai rendu tous les éléments de texte respectueux de cette démarche, mais on arrive ici sur une substance qui échappe à la découpe et à la mise à la ligne, nommée image. Malheur.
L’image a déjà à priori choisi l’espace qu’elle veut occuper. Et si on peut diminuer ou augmenter sa taille pour la taire un peu ou pour lui donner plus d’assurance sur la scène de la page, modifier ses proportions en tord le message, l’aplatit. Et “un peu plat” c’est généralement très péjoratif. Bref, l’image porte en elle cette nécessité de respecter ses proportions un minimum, à moins qu’on cherche à cacher et censurer quelque chose. Pas très digne du libriste que je suis. Que faire quand la proportion de l’image ne respecte pas la proportion suivante: 100% de largeur de colonne, et N x Grille de base?
Regardez comment ils ont massacré mon enfant! - Don Curseurone
Pour contrer ce décalage en dessous et enfin faire régner cette folie cartésienne qu’est la tombée en ligne droite et cet ordre prévisible, il faut censurer les pixels vagabonds - rogner l’image, ou bien leur laisser de la place pour qu’ils se défoulent sans contaminer les lettres - laisser de la marge. Ce qui doit avoir comme résultat final obligatoirement une hauteur multiple de notre grille de base. En dedans de ce centre pénitentiaire à marginaux atypographiques on contient les perturbations. En dehors se fait loi un ordre totalitaire pour les lettres. Un véritable cauchemar de flicage de la mise en page.
Concrètement il s’agit de placer les images, ou du moins
celles qui s’aligneront dans les colonnes, en même temps que le reste du
contenu. Puis de vérifier combien de lignes de texte elles prennent, et
seulement ensuite modifier leur hauteur dans le CSS pré-PagedJS ainsi:
height: calc(14 * 12pt);
où 14 est le nombre entier de
colonnes que prend l’image ou qu’on souhaite lui donner, et 12pt est
notre grille de base. Mais une image est de base contenue dans un
pagragraphe, et donc il nous faudra donner cette propriété à la fois à
l’image et à son paragraphe contenant. Puis, ajuster l’alignement de
l’image dans sa boite avec object-fill
.
Sauf que chaque image a sa proportion propre, et donc on ne peut créer une règle CSS globale. Il faudra alors identifier les images avec des ID dans le document Markdown ou HTML et utiliser ces identifiants spécifiques pour modifier image par image le CSS. Pffffffff…
Ce qu’on peut faire c’est: ~~~ p img { /* toute image dans un paragraphe / height: 100%; / toute la hauteur du parent / object-fit: / cover (couvre tout l’espace) ou contain (est contenue dans la boite) */ }
p:has(#identifiantduneimage) { /* paragraphe parent contenant image spécifique / height: calc( 13 12pt ); /* Pour 13 lignes de hauteur sur une grille de 12pt */ } ~~~
Comme ça toute image dans un paragraphe se verra ajustée à la taille de son parent, et on changera la hauteur en appelant les parents de chaque image particulière par son ID.
Bonus: si on a une image fortement en longueur on peut lui donner
la propriété column-span: all
pour lui laisser
confortablement s’étendre sur le champs typographique comme un patron de
la FNSEA s’étend sur le dos des revendications de petits
agriculteurs.
Des règles qui dérèglent
En ajoutant cette image au texte on s’aperçoit qu’une chose change ici:
Comme c’est décalé! Comme ça n’est point dans les règles de l’art!
Le problème vient… de moi. J’ai en effet mis en page cette seconde image avant d’avoir mis en page la première. Donc j’ai tout arrangé pour créer un décalage et espacement du texte à tel et tel endroit, chose qui marchait avant mais se retrouve maintenant les jambes coupées, rampant au mieux.
Il faut que je refasse tout ça maintenant. Morale de l’histoire? Faites vos pages une à une du début à la fin et pas en bourrin dont la connaissance plate d’un PagedJS se transforme en orgueilleux “jepeulefére”. A défaut de ne pouvoir attraper l’instant présent et de devoir obligatoirement se projeter, projetez-vous aussi peu que possible et attrapez le premier moment qui suit immédiatement, pas un truc que vous aurez à faire dans deux semaines. Bonne chance. j’ai l’air aigri mais je trouve ça rigolo! Rigolo comme ça:
Ok c’est ultra compliqué. Quand j’a fait ça la première fois, je recopiais une mise en page déjà faite une fois sur Scribus. Je pouvais calculer tout, les tailles, les césures, les moments exacts où apparaissent des images. C’est plutôt facile car on se calque sur quelque chose de déjà conceptualisé. or ce que je fais ici n’est pas de l’ordre du déjà conceptualisé et fourni, l’idée est qu’on puisse faire de PagedJS l’outil principal de mise en page de Curseurs.
Ce que je fais sur cette image, c’est essayer de bien placer des carrés d’espace blanc dans les paragraphes pour y accueillir une partie d’une image qui aura une largeur de deux colonnes, et décaler le paragraphe régulier d’une moitié de largeur pour un autre paragraphe qui fera une colonne et demi. Mais ça clash fortement et j’en ressors avec le constat suivant:
Pour des opérations pareilles, si elles sont peu et simples ça peut aller. Mais si elles sont compliquées comme celle-ci, il est très peu recommandé de s’y attaquer à moins d’invoquer un démon du rendering qui prendra votre article pour une ouija board aux runes antiques.
Je fais ça en essayant de recopier de mémoire une mise en page déjà là. J’ai pas les chiffres et toutes les mesures mais j’ai une idée à quoi ça doit ressembler. Imaginez-vous faire ça sans avoir encore même la conception abstraite de la mise en page et que vous l’inventez en cours de route. Se tirer une balle dans le pied, c’est peu dire.
Peu convaincu par la nécessiter de se broyer les doigts sur le clavier dans une tentative de sauvetage de la mise en page actuelle, je me dis qu’il serait préférable de faire un truc qui est moins canon et irrégulier, mais qui marche plus simplement.
Solution:
La solution moins canon mais plus faisable étant préférable, j’ai omis la mise en page complexe du paragraphe en jaune pour me concentrer sur l’image à deux colonnes. Ca marche, c’est pas trop moche, et c’est pas compliqué (quand on en a une). Voilà la mise en page:

Le truc rouge, c’est l’espace vide dédié à l’image, un
<span>
qui vient juste après elle dans la suite du
fichier HTML ou markdown. L’ordre image puis span est
important. Il est plutôt facile de calculer le nombre de lignes de
texte qu’elle prendra en hauteur, et on attribue ce nombre à la hauteur
du truc rouge.
Ça nous permet d’avoir une image en
position: absolute; width: 60% (de la page, un peu moins de 2 colonnes)
Le reste du texte et du contenu est quant à lui régulier dans ses colonnes. Avec quelques changements et compromis de mise en page, voilà ce que cela donne:

Bilan de la journée
- J’ai repris le travail pour la première fois sans un exemplaire de Curseurs devant moi. C’est complètement différent de quand on recopie au millimètre et à la lettre. J’en tire qu’utiliser PagedJS pour la conception intiale demande des compromis à faire dans la complexité du travail.
- Les images doivent être traitées chacune individuellement pour permettre une bonne mise en page pas cassée.
- J’appuie encore plus sur le besoin de travailler sur ces documents de manière linéaire de la première à la dernière page et non pas dans un ordre arbitraire.
- Des irrégularités (p.ex. non-respect des colonnes) sont permises si elles ne sont pas trop complexes. Sinon, on peut vite se retrouver avec des problèmes trop longs à résoudre.
Curseurs sans souris avec soucis: Day 8
Reculer pour pas se péter la tronche
Rappel: Jusqu’ici, j’ai travaillé à partir d’un document déjà mis en page et je n’ai fait que recopier le style. C’était déjà pour voir si Paged.js pouvait faire les opérations de base dont on aurait besoin. Je l’ai fait en formatant les articles en live dans du Markdown directement dans un fichier PHP. Pas organisé, mal balisé, et pas très secure. J’ai changé à la va-vite parfois le balisage et les styles de contenu.
Constat: Paged.js fait très bien le travail de base d’une mise en page rapide pour le contenu régulier. Je peux utiliser toutes les propriétés et règles CSS que je veux pour formater le contenu, même si parfois pour des opérations complexes ça demande bien plus d’investissement manuel.
Problème: Mais dans Curseurs, il y a une douzaine de types de contenu différents, des articles, des images, en passant par des paragraphes en exergue, des interruptions, des cases d’information, un sommaire, un lexique, et un éventail de styles de caractère et de texte pour ce qui est questions, termes, caractères spéciaux, texte souligné, texte barré, encadrés, italique, gras…
Question: Quelle est la solution pour un formatage et un balisage humain (pas 30 opérations par seconde) du contenu pour faciliter une automatisation partielle (elle ne pourra jamais être complète) de la mise en page? Aussi, quels compromis dans la complexité du design pour que le·a designer·e ne passe pas 100 heures dessus?
Repenser et connaître la chaîne de la rédac’ à l’impression
Questions pour la team de Curseurs (et tout autre projet qui pense adopter PagedJS):
- Comment vous vous passez le texte et les images?
- Quand est-ce que vous pensez aux encadrés?
- Quel balisage préférez-vous? markdown + HTML? HTML seul? markdown + balisage et parsing sur-mesure?
- Il faut qu’on liste les styles différents de contenus comme ça on peut les tester
Enfaite, il faut repenser comment on balise le contenu d’avance.
Si on balise tout dès le début et qu’on invente des règles CSS, il y aura un peu plus de travail sur le balisage des mots et paragraphes, et il y aura certaines restrictions sur la forme, mais l’automatisation sera plus facile car une grosse partie du contenu sera mis en page très vite. Ça laissera beaucoup plus de temps pour se pencher sur les encadrés, les exergues, les éléments non-ordinaires qui sont parfois indispensables.
Si en revanche on donne moins de temps à baliser, à inventer des styles et des règles de base, il faudra les écrire et concevoir en cours de route, et plus de temps sera passé pour écrire des styles dans le contenu ordinaire que pour régler des problèmes d’affichage et les fins détails qui font le charme d’une édition en papier.
Les tags HTML custom sont super pour le balisage. On s’en fout que c’est du bad practice pour l’accessibilité web. Ceux et celles qui travaillent sur Curseurs seront contraint·es à utiliser une version récente de Chromium et que sur leur ordi. Que le boîtant Raspberry Pi 2+ du fond du grenier n’arrive pas à afficher le résultat à 320 pixels sur son navigateur Epiphany datant de 2008 et l’imprimer sur l’antique Konica-Minolta au plastique jauni de mon grand-père qui prend plus de temps à se mettre en route que la durée de mon stage,c’est pas grave.
Le balisage par tags custom, type
<sommaire> <lexique> <terme> <exergue>
qui n’ont aucun style par défaut sont parfaits pour facilement remplacer
les longs <div class="sommaire" id="toc-page1">
. Ils
sont plus rapides à écrire et à lire car sémantiques. Sur eux, on peut
placer des règles CSS comme bon et beau nous semble.
Repenser le style
Si on sacrifie certaines spécificités graphiques et stylistiques, telles les images entre les colonnes, les contenus qui prennent deux colonnes dans un arrangement de trois, etc, ou qu’on les réduit en fréquence au moins, et ça au début, on passera moins de temps à tout styliser individuellement. La mise en page automatique de PagedJS (calquée sur les règles faites main hein) sera plus efficace et on aura plus de temps pour ajouter des features non-ordinaires plutôt que de réparer des beugs faits par ces trucs non-ordinaire.
Pour ça, il faut une base solide de règles CSS qu’on définit comme le modèle de base de la revue. Et ça, ça dépend d’un balisage solide aussi. Le travail dur et embêtant d’abord pour pouvoir ensuite jouir de la mise en page.
For us — hatred, war and destruction; for them — love, peace and happiness.
- Carlo Cafiero
Structure
Il faut repenser la structure du dossier car tout est pour l’instant désorganisé, mis en amas à la racine du dossier. Ça permet de mieux se retrouver.
Dossier | Contenus |
---|---|
racine | index.php , README.md ,
TODO.md , composer.lock ,
composer.json |
vendor | les librairies PHP composer, parsedown, jolicode |
images | toutes les images du numéro |
js | paged.polyfill.js , postlayout.js |
css | interface.css , base.css ,
specific.css , postlayout.css |
fonts | fichiers des fontes et leurs feuilles de style correspondantes |
C’est pour demain.
Curseurs gegen soucis: Day 9
Pages master
Paged.js a une fonctionnalité super. Elle est parfois dre à naviguer mais elle est super. C’est celle des Named Pages. C’est des pages master, des templates nommés qu’on peut associer à du contenu. Exemple: ma deuxième page, juste après la couverture, c’est un édito et un sommaire. On va typiquement prendre une ou max deux pages pour ça, si l’édito est plus long ou si les pages devant vous ont plus de trucs à dire. Disons maximum deux pages.
Si on englobe tout ça dans une section qui s’appelle
<intro>
, Il devient possible de lui assigner une page
nommée et d’avoir des styles particuliers là. On a dans cette page là
une section <edito>
et une
<sommaire>
. Ça change pas énormément de choses, mais
notre contenu et son style sont un peu mieux organisés:
Edito
<p>Bonjour voici la note de l'équipe</p>
<p>Ceci est un deuxième paragraphe</p>
</edito>
<sommaire>
<h1>Sommaire</h1>
<ul>
<li>Article 1</li>
<li>Article 2</li>
<li>Article 3</li>
</ul>
</sommaire>
CSS: ~~~ intro { page: introToc; }
@page introToc { /* règles pour la page en général / & sommaire ul { / règles pour la liste du sommaire Dans la page d’intro */ }
& edito p {
/* règles pour les paragraphes de l'édito dans la page d'intro */
}
} ~~~
C’est une bonne façon de ne pase devoir répéter des sélecteurs CSS 36 fois. Après faut faire gaffe à pas trop abuser avec. Trop d’embranchement crée du trouble.
Il faut essayer de ne pas créer des balises custom qui remplacent les
éléments textuels comme
<p> <h1>-<h6> <ul> <ol> <li> <a> <img>
etc qui contiennent certaines propriétés qu’on veut garder.
Les balises custom: pas pour les capricieux
J’ai dit un truc pas fou hier. Les balises HTML custom marchent bien
pour les fonctionnalités HTML de base et les règles CSS pas trop
capricieuses. Or si on a appris un truc c’est que nos trois colonnes
sont capricieuses. Ainsi, elles marchent pour la balise
<article>
mais pas pour une custom appelée
<content>
. Je me sens un peu bête.
Ahem.
Jusque là, j’avais pas de balise regroupant le contenu et le titre de
l’article. Comme mon contenu est en trois colonnes mais le titre non, je
pensais qu’il vaut mieux les séparer. Je vois qu’il m’est
possible de les regrouper en donnant un column-span:all
aux
titres pour qu’ils s’étalent sur toute la page.
Deux choix:
- On garde les balises classiques reconnues par les navigateurs. On groupe le contenu en section puis en article. Puis en paragraphe, puis span, et juste à la fin de l’article on fait une div pour des notes. On obéit à toutes les règles HTML et CSS et on fait pas le ninja.
- On crée notre propre système de balisage, et on crée un parseur
(léger) PHP pour convertir ces balises en
<div class="nom-de-balise" markdown="1">
. Plus d’effort au début pour après avoir plus d’aise.
regardez, le CSS est un peu plus organisé: