Génération de PDF depuis des applications Web en Python

weasyprint

from weasyprint import HTML, CSS
html = my_template()
data = HTML(string=html).write_pdf()

reportlab

<tal:if tal:condition="not: formulas/validated">
  <fill color="yellow"/>
  <stroke color="black"/>
  <rect x="115mm" y="217mm" width="90mm" height="18mm"
        fill="yes" stroke="yes"/>
  <frame id="warning" x1="115mm" y1="213mm" width="90mm" height="24mm"  />
  <fill color="black"/>
  <stroke color="black"/>
</tal:if>

<story>
  <para style="warning" tal:condition="not: formulas/validated">
    CECI EST UN DOCUMENT PROVISOIRE NON VALIDÉ - NE PAS IMPRIMER
  </para>
</story>

pdftk

pdftk est une boite à outils permettant de manipuler des PDF. Elle ne permet pas directement de générer des PDFs, mais permet de les transformer ensuite, par exemple extraire des pages, concaténer des PDF, ou imprimer un calque en surimpression sur un fond.

Il s'utilise en ligne de commande, en Python il faut donc utiliser subprocess (ou os.system ou équivalent).

LaTeX

Autres pistes

Quelques autres outils et pistes possibles sont listées rapidement :

• il existe des bibliothèques JavaScript pour faire du rendu PDF côté client, et non côté serveur ;
• il est possible d'utiliser LibreOffice via la bibliothèque python-uno, pour convertir à la volée des documents LibreOffice (ou éventuellement MS Office) en PDF, cependant le déploiement est relativement lourd (il faut lancer un LibreOffice en mode serveur).

Les en-têtes HTTP

Lorsqu'on renvoie au navigateur un document PDF, il faut indiquer le type de document via l'en-tête HTTP Content-Type, avec quelque chose du type

response.setHeader('Content-Type', 'application/pdf')

Il est aussi possible d'indiquer au navigateur si on souhaite que le document soit affiché dans la fenêtre du navigateur (pour les navigateurs qui le supportent) ou téléchargé, via l'en-tête Content-Disposition, par exemple

response.setHeader('Content-Disposition', 'attachment; filename="%s.pdf"' % filename)

Attention, il s'agit d'un souhait, le comportement exact peut varier d'un navigateur à l'autre (et suivant la configuration de l'utilisateur).

Le temps de génération

Lorsqu'on génère des PDF de taille important (plusieurs dizaines ou centaines de pages), quelle que soit la technologie utilisée, le temps de génération peut être long, plusieurs minutes facilement, ce qui peut provoquer des timeout à plusieurs niveaux.

Les solutions envisageables sont :

• Augmenter les temps de timeout sur tous les composants impliqués (apache, gunicorn, varnish, etc.). Penser à prévenir l'utilisateur, et à prévoir un mécanisme (par exemple désactiver le bouton en JS une fois que l'utilisateur a cliqué dessus) pour éviter que l'utilisateur impatient ne provoque plusieurs générations du même document en parallèle.

• Informer l'utilisateur que son document va lui être transmis par mail, lancer la génération dans un processus annexe (via fork ou via un ordonnanceur de tâches comme Celery ou équivalent), et envoyer un mail avec soit le document en pièce jointe (mais attention les gros mails peuvent être bloqués), soit un lien de téléchargement dans le mail. Penser dans ce cas à nettoyer les fichiers laissés sur le serveur au bout de quelques jours (ou semaines), via un cron par exemple

  find /path/to/generated/pdfs -mtime +14 -delete
  

• Lancer le processus en asynchrone, et mettre en place un mécanisme en JavaScript pour interroger le serveur régulièrement, et indiquer à l'utilisateur quand le fichier est généré.

Les moteurs de recherche

Souvent la génération PDF est réservée à des utilisateurs authentifiés sur le site, mais parfois elle est disponible pour les anonymes. Par exemple une fonctionnalité régulièrement demandée est de mettre un bouton "PDF" sur toutes les pages d'un CMS pour permettre aux visiteurs de les récupérer.

Dans ce cas il faut faire très attention à ce que les moteurs de recherche, ou autres robots, ne se mettent pas à demander une version PDF de toutes les pages, ce qui peut rendre le site temporairement indisponible.

Il y a plusieurs solutions palliatives pour ce problème :

1. Utiliser le fichier robots.txt, mais vu que le support des regexp dans ce fichier n'est pas standard, ce n'est souvent pas possible sans un travail délicat de réécriture des URL.
2. Mettre la génération PDF en POST et non en GET, c'est une légère entorse au protocole HTTP (puisque la génération PDF ne modifie pas d'information), mais qui bloque la plupart des robots ne suivant pas les POST.
3. Mettre des règles en amont (par exemple sur un reverse-proxy type haproxy) pour limiter le nombre de génération PDF simultanées sur le site, ainsi en cas de génération massive de PDF, seule la fonctionnalité est bloquée, et non l'ensemble du site.

L'utilisation de ressources machine

Ce point est lié aux deux précédents. La génération de PDF peut demander des quantités importantes de mémoire (en particulier Weasyprint peut prendre plus d'1 Go lorsqu'on génère des fichiers de plusieurs centaines de pages), et de multiples générations en parallèle peuvent utiliser massivement le CPU.

Quelques astuces pour limiter ces problèmes :

1. Avant toute mise en production, effectuer une estimation des ressources nécessaires, et dimensionner en conséquence l'hébergement.

2. Comme pour le temps de génération élevé, utiliser un ordonnanceur de tâches afin de s'assurer qu'une seule génération est effectuée à la fois.

3. Si la génération est faite via un processus externe (Weasyprint, pdftk, LaTeX, ...) il peut être recommandé d'utiliser taskset (pour affecter un cœur de CPU dédié au processus) et/ou nice (pour affecter une priorité au programme), par exemple en utilisant un petit script de ce type pour envelopper les appels

   #!/bin/sh
   exec nice -n 10 taskset -c 0 /usr/bin/pdftk "$@"
   

4. Mettre en place un système de cache, pour garder les PDF générés et ne les générer de nouveau que si les données ont changé.

L'accès aux ressources (CSS, images)

Ce problème concerne surtout Weasyprint, mais peut aussi concerner d'autres solutions similaires : parfois certaines ressources référencées par un document (images, CSS, ...) ne sont pas accessibles publiquement mais nécessitent d'être authentifiés.

Trois solutions existent alors :

1. Récupérer le cookie de connexion de l'utilisateur, et le communiquer à l'outil.
2. Récupérer tous les éléments, les déposer dans un répertoire temporaire, réécrire les URLs pour avoir des références locales, et nettoyer le tout à la fin de la génération.
3. Modifier le contrôle d'accès pour que les ressources utilisées lors de la génération PDF fonctionnent même en anonyme, par exemple via un filtre sur l'adresse IP source (mais faire très attention à ne pas laisser de trou avec cette solution).

Les PDF chiffrés (DRM)

Un scénario qui revient dans plusieurs projets est le suivant :

1. Un utilisateur rempli un formulaire, comportant des champs textes mais aussi un champ fichier, où il doit mettre un PDF.
2. Un rendu de son formulaire est fait, incluant ses réponses textes puis en annexe le PDF qu'il a inclus. Voir même un export de toutes les réponses de tous les utilisateurs dans un gros PDF, pour l'administrateur du site.

C'est un cas typique d'utilisation de Weasyprint + pdftk (ou de LaTeX). Mais parfois, à la génération, le tout échoue sans que la raison ne soit évidente.

En fait l'utilisateur a saisi un PDF protégé via du DRM, et l'outil pdftk (ou pdflatex) n'arrive pas à l'intégrer dans son propre PDF (ce serait violer les conditions du document).

Il existe des techniques de contournement, mais qui peuvent poser des problèmes de légalité.

Une autre solution consiste à rejeter les PDF protégés par du DRM lors de la validation du formulaire, en utilisant un outil comme pdfinfo (venant de poppler ) par exemple

st, out = commands.getstatusoutput('pdfinfo %s' % pdffile)
if st or re.search('Encrypted:.*yes', out):
    raise ValueError, "this PDF file is DRM protected"