Pendant longtemps pour générer des vues PDF pour un node, il n'y avait guère d'autre solution que TCPDF ou DOMPDF, via le module PdfView ou plus récemment Printer. Aujourd'hui, il existe une nouvelle méthode native et diablement efficace utilisant le célèbre moteur webKit.

État des lieux

Sous Drupal, il existe au moins deux modules qui permettent d'obtenir la version PDF d'un contenu : pdfview et printer. Le second est plus récent, un peu plus bordélique aussi, mais propose outre le PDF, l'expédition d'un article à un ami, et une version imprimable. Ca ne se refuse pas...

Le module printer pouvait (et peut toujours d'ailleurs) être paramétré pour utiliser l'une des deux librairies PHP parmi les plus connues pour générer du PDF : DomPDF et tcpdf. Je dis les plus connues car il existe un autre projet tout jeune (et français) qui cherche à se faire une place, HTMLtoPDF.

Tout serait parfait sauf que la DOMPDF gère les accents comme il peux pour planter le reste du temps, et TCPDF ne prend pas en compte les feuilles de style. Et cerise sur le gâteau, les deux sont loin d'être des foudres de guerre... Donc en attendant de tester une éventuelle inclusion de HTMLtoPDF, le sujet est donc un peu mort du côté "pur PHP".

WebKit avec Drupal

Depuis peu, printer inclus une troisième option bien plus intéressante pour qui a la main sur son serveur, l'utilisation directe du moteur de rendu WebKit à travers l'outil wkhtmltopdf.

khtmltopdf utilise WebKit (Pour les rares qui ne le savent pas encore, il s'agit du moteur de rendu de Konqueror, Safari ou encore Google Chrome) pour un rendu visuel fidèle d'une page HTML et des ses feuilles de style, et le système d'impression de Qt4.5 pour transformer le tout en PDF. Le système fonctionne sous *nix ET sous Windows (les binaires sont fournis sur le site).

Sous *nix, Qt basant sa gestion des pixmaps sur X11, nous allons avoir en plus besoin de ce serveur pour fonctionner. Enfin, pas exactement de ce serveur, mais d'un utilitaire bien utile qui simule en mémoire le protocole X11, Xvfb. Une fois l'outil installé, le plus simple est d'en faire un lien symbolique dans la racine du module printer.

Pour ce qui est de la compilation de khtmltopdf sous linux, vous trouver toutes les informations utiles ici. Ensuite, pour Linuxiens et Windowiens, il ne reste plus qu'à déplacer (ou symlinker) le binaire khtmltopdf, lui aussi, dans à la racine du module.

Paramétrage de Printer

Pour commencer, vous devez activer (au minimum) les modules suivants :

• Printer-friendly pages (core)
• PDF version

Ensuite, allez dans Configuration du site, puis sur l'onglet PDF. Vous devriez alors voir apparaître en haut de la page un bouton radio avec comme libellé le chemin complet vers wkhtmltopdf. Activez ce bouton radio pour que printer utilise bien wkhtmltopdf. Ceci fait, cochez Link area pour que le lien d'impression PDF soit ajouté à ceux des contenus, puis descendez en bas de la page.

Vous avez ici les options pour wkhtmltopdf, supprimez tout ce qui s'y trouve. Ces options ne sont en effet pas compatible avec la version 0.8. Une fois la zone vidée, les Unixiens constaterons que juste en dessous se trouvent les options pour Xvfb. En effet, Printer va directement lancer lui-même le faux serveur X11 avant wkhtmltopdf, sans que vous n'ayez rien à faire de plus (pas besoin de créer un service donc).

Vous pouvez maintenant enregistrer la configuration et aller sur un contenu pour cliquer sur le lien PDF et vérifier ainsi que tout fonctionne.

Mise en cache du PDF

La génération a beau être beaucoup plus véloce qu'avec n'importe quelle librairie PHP, il n'en reste pas moins ridicule de générer systématiquement un PDF à chaque click. Le mieux serait de le générer la première fois, de le stocker sur le serveur et de le servir de manière statique, via apache, les fois suivantes.

Pour faire cela, j'ai bidouillé un module expérimental qui s'inspire trééés fortement de l'excellent imagecache que j'ai appelé en tout originalité anycache.

Le principe est de mettre sur la page un lien vers files/anycache/pdf/NID.pdf (typiquement dans le node.tpl.php). Lorsque l'utilisateur click dessus la première fois, Apache ne trouve pas le fichier et génère une 404 qui est transmise à Drupal. Le module AnyCache intercepte ce chemin, cherche un sous-module qui gérerait le domaine /pdf/ et lui transmet la demande de génération.

AnyCache est conçu de sorte à ce que l'on puisse facilement construire des modules qui servent de "handler" pour un domaine donné. En standard, il y a dans AnyCache un module d'exemple appelé pdf_printer qui gère justement ce domaine. Son seul rôle est de faire appel à la génération PDF du module Printer et de renvoyer stocker le résultat dans le chemin de fichier (files/anycache/pdf/NID.pdf) que lui aura fourni AnyCache. En retour, AnyCache déclenche le download du fichier généré, fin de l'histoire.

Pour le second click sur le lien, Apache détecte la présence du fichier files/anycache/pdf/NID.pdf et le renvoie directement à l'utilisateur, SANS faire appel à Drupal.

Pour compléter le dispositif, le module pdf_printer implémente nodeapi pour détecter une modification sur un node et ainsi détruire l'éventuel pdf associé de sorte à ce que la génération puisse se faire au prochain coup.

En réalité pas tout à fait fin de l'histoire car Printer est un tout petit peu développé à la "vas-y que j'te pousse", avec pour conséquence l'implémentation du download dans chacun des plugins qui gère une librairie HTML/PDF, et donc aussi dans celle de wkhtmltopdf. La conséquence est qu'il n'y a pas de moyen propre de faire appel à la méthode de rendu de printer sans se coltiner la génération d'en-tête HTTP qui vont rentrer en conflit avec ceux d'anycache. La solution est donc à commenter, dans print_pdf.pages.inc comme ceci :

  /*
  header("Cache-Control: private");
  header("Content-Type: application/pdf");

  $attachment =  ($print_pdf_content_disposition == 2) ?  "attachment" :  "inline";

  header("Content-Disposition: $attachment; filename="$filename"");
*/
  echo $pdf;
  /*
  flush();
  */

suppression de la génération des headers

Pas terrible j'en conviens. Si cela vous amuse de tenter ce mécanisme, le module est disponible ici.

Conclusion

L'intégration de wkhtmltopdf à Printer est une bonne nouvelle pour la génération de PDF sous Drupal, permettant un rendu beaucoup plus propre en prenant beaucoup moins de ressources. Le seul inconvénient est que les liens ne seront pas clickables, mais en soit, ce n'est pas bien grave.