Phenix a écrit :
Ma question principal est : pourquoi avoir choisi d'utiliser wkhtmltopdf
alors qu'il y a déjà, sur la zone, un outil pour convertir du html en
PDF : dompdf
Connexion · GitLab ?
Contrairement à wkhtmltopdf, dompdf fonctionne sans avoir à installer
quoi que ce soit sur le serveur. Ilme semble donc plus approprié.
Pour avoir essayé à peu près toutes les libs PHP de generation de PDF sur ces 10 dernières années, j'en suis arrivé à la conclusion que de telles libs ne peuvent pas avoir un rendu fiable et correct d'un document HTML/CSS quelconque et obligent à faire plein de bidouilles pour que ça marchotte.
La raison principale et essentielle est que HTML n'est pas traduisible en PDF, et que la PDFisation d'un document HTML n'est ni plus ni moins qu'un rendu visuel d'un document HTML (exprimé en commandes PDF au lieu de px).
C'est exactement le travail d'un moteur de rendu de navigateur (Gecko, Blink, WebKit…). Quand on voit la complexité de ces moteurs de rendu et les ressources que cela nécessite chez les développeurs de navigateur pour les maintenir fonctionnels, il serait illusoire de penser qu'il sera possible de faire aussi bien avec une librairie PHP maintenue par quelques mainteneurs, sans leur faire offense.
J'avoue ne pas avoir essayé DOMPDF, mais je ne pense pas qu'elle échappe totalement à l'analyse, et ce que je peux lire sur GitHub - dompdf/dompdf: HTML to PDF converter for PHP :
"At its heart, dompdf is (mostly) a CSS 2.1 compliant HTML layout and rendering engine written in PHP." [ ce qui exclu donc CSS3 ]
"Dompdf is not particularly tolerant to poorly-formed HTML input. To avoid any unexpected rendering issues you should either enable the built-in HTML5 parser at runtime ($dompdf->set_option('isHtml5ParserEnabled', true)
or run your HTML through a HTML validator/cleaner (such as Tidy or the W3C Markup Validation Service)."
"Large files or large tables can take a while to render."
"CSS float is in development and may not produce the desired result"
Mon besoin est d'avoir un rendu propre, fiable, complètement contrôlable en HTML/CSS et dont je suis sûr qu'il couvrira tous les cas que je vais rencontrer (et pas avoir des documents PDF à demi blanc au hasard des bugs et problèmes techniques de rendu, comme j'ai pu l'expérimenter avec les lib sus-citées).
Pour le moment PrinceXML était la seule solution qui remplissait ce besoin, mais avec un coût inacceptable pour les petits projets.
J'ai réessayé récemment WKHTMLTOPDF qui s'appuie sur le moteur webkit de Safari, et j'ai pu voir qu'on obtenait de très bon résultats, d'où mon choix.
Maintenant comme tu auras pu le lire dans le code, j'ai adressé le problème de l'execution binaire de plusieurs façons :
- le plugin peut servir d'API http pour d'autres sites. Ainsi tu peux l'installer sur un SPIP dédié sur un hébergement qui te permet d'avoir wkhtmltopdf, et ensuite l'utiliser comme API wkhtmltopdf pour d'autres sites qui n'auront pas besoin du binaire en local
- la fonction de génération "generer_pdf_version_objet" est chargée par charger_fonction, ce qui la rend tout à fait surchargeable. Tu peux ainsi en écrire ta propre version dans le plugin DOMPDF qui viendra prendre la main et faire le rendu via la lib DomPDF, et te donner exactement ce que tu veux en combinant les 2 plugins
Pour le moment je préfèrerai qu'on en reste là sans intégrer DOMPDF au plugin pdf_version, car pour moi il ne remplit pas le besoin, mais je suis ouvert à regarder ça de plus près quand tu auras une intégration de l'un à l'autre qui fonctionne et que je peux tester.
Cédric
