Convertir HTML en PDF

Moins que ce que l’on imagine. Un document HTML, ce sont la structure et les mots : titres, paragraphes, tableaux, et des renvois vers tout le reste. La feuille de style qui lui donne son allure est le plus souvent un fichier séparé, désigné par une adresse. Les polices, les images et les scripts aussi.

Quand vous ouvrez un tel fichier dans un navigateur, celui-ci va chercher tout cela et assemble la page devant vous — c’est pourquoi elle paraît complète et pourquoi le fichier donne l’impression de contenir une page web. Il ne la contient pas. Confiez le même fichier à quelque chose qui ne peut rien aller chercher, et il ne reste que le texte, dans la police par défaut, sur une colonne.

Il serait techniquement possible de suivre ces liens et de télécharger la feuille de style, les polices et les images. Nous ne le faisons pas, et la raison mérite d’être dite franchement : un convertisseur qui va chercher les URL trouvées dans les fichiers de ses visiteurs est une machine que l’on pointera volontiers vers des adresses internes dès que quelqu’un aura compris qu’elle va chercher.

Le serveur de conversion n’a ici aucune route vers l’internet. C’est la propriété même qui garantit que votre document ne peut être envoyé nulle part, et elle implique nécessairement qu’une feuille de style liée est un lien vers rien. Ce sont les deux faces d’une seule décision.

Autonome, c’est toute l’exigence. Mettez le CSS dans un bloc `<style>` à l’intérieur du document au lieu de le lier. Intégrez les images en data URI — du base64 dans l’attribut `src` — plutôt que de pointer vers des fichiers. Utilisez des polices présentes sur un système ordinaire, car une police web servie par un service de fontes n’arrivera pas.

Quantité de documents générés fonctionnent déjà ainsi : les factures d’un logiciel de comptabilité, les rapports d’un outil d’analyse, les exports d’applications de prise de notes et la plupart des modèles de courriel HTML sont bâtis autonomes précisément pour survivre aux transferts. Ceux-là se convertissent avec leur mise en page intacte. Une page enregistrée depuis un navigateur par « Enregistrer sous » n’y arrive presque jamais, parce que cela produit un fichier HTML et, à côté, un dossier de ressources.

Si le but est de garder une copie d’une page que vous avez sous les yeux — un article, un reçu, une confirmation de réservation, une page qui pourrait disparaître — fermez cet onglet et faites Ctrl+P, ou Cmd+P sur un Mac, puis choisissez « Enregistrer au format PDF ».

Le navigateur a déjà fait le plus dur. Chaque feuille de style est chargée, chaque police résolue, chaque image récupérée, chaque script exécuté. Il produit un PDF à partir de la page finie et non d’un fichier qui la décrit, et aucun convertisseur extérieur ne peut égaler cela, faute de disposer de la page assemblée. Cette page existe pour les fichiers HTML que vous détenez ; pour les pages que vous consultez, le meilleur outil est déjà ouvert.

Le document est composé sur des pages standard avec la typographie par défaut du convertisseur, sauf si le fichier porte ses propres styles. Il n’y a pas de fenêtre à laquelle s’adapter : une mise en page conçue pour un écran se voit donc poser une question pour laquelle elle n’a pas été dessinée.

Tout ce qui utilise des styles d’impression dans son CSS s’en servira, et c’est exactement le mécanisme dont un document bien construit dispose déjà pour ce cas. Tout ce qui compte sur JavaScript pour s’organiser n’aura rien, puisque rien ne s’exécute.

Les liens textuels sont conservés comme liens dans le PDF : une URL présente dans le document reste cliquable. Les ancres internes pointant vers d’autres endroits du même document fonctionnent également.

Les liens vers des fichiers qui se trouvaient à côté du HTML pointeront vers des adresses qui ne mènent plus nulle part. Ce n’est pas un défaut de la conversion : c’est ce qui arrive quand un document qui dépendait de ses voisins est déplacé tout seul.

Un écran défile latéralement, une page non : il faut donc bien faire quelque chose d’un tableau large. Les colonnes se compriment, et au-delà d’une certaine largeur le texte devient trop petit pour être lu alors que le tableau reste techniquement complet.

Si le document est essentiellement un large tableau, tranchez avant de convertir plutôt qu’après : réduisez le nombre de colonnes, ou déclarez un format de page à l’italienne dans le CSS, que la conversion respectera.

Ce sont les fichiers qui se convertissent le mieux, et ce n’est pas un hasard. Factures issues d’un logiciel de comptabilité, rapports d’analyse d’audience, exports d’applications de notes et la plupart des modèles de courriel HTML sont construits autonomes pour survivre au fait d’être transférés.

Tout ce dont ils ont besoin tient dans un seul fichier, ce qui est précisément la propriété que cette conversion exige. Si votre HTML vient de l’un d’eux, attendez-vous à un résultat correct.

Rien de ce que contient le fichier n’est exécuté. Une page qui fabrique son contenu en JavaScript se convertit en ce que dit le balisage avant que le script n’ait tourné, ce qui représente fréquemment très peu de chose.

C’est une propriété de sûreté et non une limite à contourner : exécuter du code trouvé dans le fichier déposé par quelqu’un n’est pas une chose à faire pour sauver une mise en page. Si le contenu n’existe qu’après l’exécution d’un script, imprimez depuis votre navigateur.