D'Adobe à Affinity, puis au code : mon parcours pour reprendre la mise en page

Après plusieurs années d’utilisation intensive de la suite Adobe, j’ai remis les mains dans la mise en page en créant un magazine d’entraînement de cinq pages avec Affinity by Canva (dans sa partie Mise en page). Envie de tester l’outil en profondeur, et une question a fini par prendre toute la place : est-ce que je ne pourrais pas faire la même chose en code gratuitement ? Un PDF, c’est du XML ou du HTML ? Me voilà parti pour un détour par le code, avec HTML et CSS, pour produire un PDF prêt à l’impression. Le chemin est encore long, mais les premiers résultats sont encourageants.

Le point de départ : Affinity by Canva pour retrouver la main #

L’objectif initial était simple : reprendre en main la mise en page avec Affinity by Canva (partie Mise en page), sur un projet concret plutôt qu’un tutoriel. Le support choisi est un magazine d’entraînement au format A4 portrait, cinq pages en vis-à-vis : une couverture, un sommaire à trois entrées, puis trois articles techniques (formats d’images, formats de polices, types de documents).

Affinity reprend une bonne partie des réflexes acquis sur InDesign : gestion des calques, outils vectoriels, export CMJN natif pour l’impression. La bascule ne pose pas de problème particulier une fois les raccourcis retrouvés. Mais un projet de plusieurs pages avec un gabarit typographique fixe (titres en serif, corps de texte en sans-serif, valeurs techniques en monospace) fait vite apparaître une limite : chaque ajustement de texte, chaque changement de grille, chaque correction de couleur repasse par une manipulation manuelle dans l’interface. Tout est très chronophage, et le risque d’erreur est réel : un calque oublié, une image mal exportée, un texte qui dépasse de la zone prévue. Le gain de temps promis par Affinity par rapport à InDesign est réel, mais il reste limité par la nature même du logiciel : un outil graphique qui demande une manipulation manuelle pour chaque changement.

Comment remplacer InDesign et Affinity par du code? #

Plutôt que de tout faire à la main dans Affinity, j’ai testé une autre approche pour la mise en page elle-même : écrire le document en HTML et CSS, avec les CSS Paged Media (les règles @page qui gèrent la pagination, les marges, les fonds perdus et les marques de coupe, normalement réservées à l’impression).

L’idée : si la mise en page est du code, elle devient reproductible, versionnable avec Git, et modifiable en quelques secondes plutôt qu’en rouvrant un fichier source et en repositionnant des blocs.

• Est-ce qu’on a l’équivalent des gabarits de page en CSS ? Oui, avec les règles @page et les sélecteurs de page (:first, :left, :right).
• Est-ce qu’on peut gérer les marges, les fonds perdus et les marques de coupe ? Oui, avec les propriétés margin, bleed et marks de la règle @page.
• Est-ce qu’on a l’équivalent des styles de texte et de paragraphes ? Oui, avec les propriétés CSS classiques (font-family, font-size, line-height, text-align, etc.) et les sélecteurs de classes ou d’éléments HTML.
• Est-ce qu’on peut gérer les images et les couleurs ? Oui, avec les balises <img> et les propriétés CSS (color, background-color, filter, etc.). (Spoiler alert : c’est précisément là que les ennuis vont commencer.)

Toutefois, cela restait encore laborieux : le rendu final en PDF n’était pas encore satisfaisant, et la gestion des couleurs CMJN était un point critique pour l’impression professionnelle. En cherchant une solution, je suis tombé sur Vivliostyle, un moteur de rendu HTML/CSS vers PDF qui promettait justement de gérer les couleurs CMJN. L’idée était séduisante : si le moteur de rendu pouvait produire un PDF prêt à l’impression avec les bonnes couleurs, alors le code pourrait devenir un outil viable pour la mise en page.

Vivliostyle : un premier essai prometteur mais limité #

Premier essai avec Vivliostyle, un outil (nécessitant Node.js) qui s’appuie sur Chromium pour interpréter les CSS Paged Media et produire un PDF.

Quelques tests plus tard, le rendu à l’écran était concluant, mais un contrôle plus poussé (ouverture du PDF final dans Affinity) a révélé un problème de fond : le fichier restait en RGB de bout en bout.

Chromium calcule bien les couleurs CMJN demandées en CSS, mais écrit ensuite du RGB dans le PDF. Ce n’est pas un réglage manquant, c’est une limite architecturale du moteur de rendu utilisé par Chromium (Skia) : aucun outil basé sur un navigateur, qu’il s’agisse de Vivliostyle, de Paged.js ou de Playwright, ne peut produire de CMJN natif dans le PDF final.

Me voilà bien remonté, prêt à m’arracher les cheveux : pour un usage prépresse réel, un flux qui prétend gérer la couleur professionnelle mais qui la convertit silencieusement en RGB est juste… bon bref, je dois trouver une autre solution.

WeasyPrint : une alternative crédible pour l’impression ? #

Direction WeasyPrint, un autre moteur de rendu HTML/CSS vers PDF, écrit en Python, qui n’a pas cette dépendance à un navigateur. Son pipeline PDF indépendant promet d’écrire du CMJN natif et d’embarquer un vrai profil ICC via une option dédiée.

Ce dernier semble cocher presque toutes les cases : rendu fidèle à l’écran, gestion des couleurs CMJN, export de PDF prêt à l’impression. Le moteur est encore jeune et la documentation limitée, mais le projet est actif et les développeurs réactifs.

Mais tu dois t’en douter : le chemin n’est pas encore tout tracé.

• Premier constat : WeasyPrint n’a pas de mode prévisualisation à l’écran par défaut. Il faut donc générer un PDF à chaque modification, ce qui peut vite devenir pénible.
• Deuxième constat : la gestion des couleurs CMJN demande de la rigueur. Pour un PDF d’impression propre, il faut lui passer --output-intent="--fogra39" pour embarquer le profil ICC.
• Troisième constat : WeasyPrint ne convertit pas les images de lui-même. Un document destiné à l’impression doit contenir des photos en CMJN à 300 DPI et des profils colorimétriques corrects. Et ça, WeasyPrint ne le fait pas à notre place.

Les solutions : des scripts pour automatiser les tâches répétitives #

Alors maintenant, il faut combler les manques :

• Un script shell qui surveille les fichiers HTML avec inotifywait et relance le build à chaque sauvegarde (./scripts/watch-build.sh magazine.html).
• Un script basé sur ImageMagick qui convertit un lot d’images en CMJN avec les bons profils colorimétriques (sRGB.icc vers FOGRA39L_coated.icc) et l’option -black-point-compensation pour ne pas boucher les ombres.
• Un troisième script en Python qui transforme les couleurs d’un SVG en couleurs CMJN (device-cmyk) sans passer par une rastérisation qui ferait perdre la transparence. Et là, je vous épargne les détails de la galère pour comprendre la mécanique, trouver les bons profils ICC et les bons paramètres de conversion.

Rien de spectaculaire, mais un vrai gain de temps dès que le document compte plusieurs pages avec des éléments répétés (gabarits de couleur, formats d’image, structure de grille). Ce qui aurait demandé de rouvrir un fichier Affinity, de resélectionner un calque et de refaire un export devient une commande qui s’exécute en quelques secondes.

Les limites rencontrées, sans les enjoliver #

Ce chantier n’a rien d’un long fleuve tranquille. Plusieurs pièges très spécifiques aux CSS Paged Media ont demandé des heures de vérification par lecture directe du PDF (avec des outils comme mutool ou pdftoppm) plutôt que par simple inspection visuelle :

• Un fond pleine page avec bleed géré par une marge négative sur un élément HTML laisse une bande blanche résiduelle en bas de page, un bug de fragmentation qu’on ne résout qu’en passant directement par la propriété @page.
• Le bleed déclaré seul, sans les marques de coupe (marks: crop), est ignoré silencieusement, sans le moindre message d’erreur.
• Les textes dans les logos SVG : l’interprétation directe des balises de texte peut réserver des surprises de rendu. Rien n’empêche de vectoriser les textes en amont lors de l’export pour être tranquille, mais le sujet mérite encore d’être creusé.
• Les images bitmap ne sont jamais converties automatiquement en CMJN par les outils de rendu HTML, il faut un script dédié à part.

Ce ne sont pas des détails anecdotiques : chacun de ces points, sans vérification appropriée, produit un PDF qui semble correct à l’écran mais qui ne l’est pas une fois imprimé.

Le résultat final #

Voici le magazine de 14 pages généré avec ce flux HTML/CSS et WeasyPrint :

Bilan à ce stade : prometteur, mais encore jeune #

Je n’ai pas réinventé la roue, mais j’ai trouvé un flux de travail qui me permet de reprendre la main sur la mise en page, avec un code HTML/CSS versionnable et reproductible. L’expérience a été enrichissante car cela m’a permis de comprendre vraiment pourquoi le choix du profil ICC et de la conversion colorimétrique est critique pour l’impression professionnelle, et pourquoi un logiciel graphique reste indispensable pour la création graphique et le contrôle final.

Le code n’a pas vocation à remplacer le logiciel de mise en page, mais à reprendre la main sur les tâches répétitives et vérifiables, là où un logiciel graphique demande une manipulation à chaque fois.

Sources et références #

• Spécification W3C CSS Paged Media Module Level 3
• Documentation officielle de WeasyPrint
• Vivliostyle Project
• ImageMagick