Add chromedp PDF converter

[fabian-z]

This PR adds chromedp as a new PDF conversion driver alongside the existing Gotenberg and WeasyPrint options.
Key benefits:

• Runs without requiring an external server (automatically finding an installed Chrome / Chromium)
• Operates in headless mode
• Supports modern web standards through Chrome's rendering engine
• 30-second timeout protection by default
• Preserves CSS page styling with PreferCSSPageSize
  • This lead to better results in testing than with Gotenberg (e.g. A4 page size with default template)

The implementation handles page loading events efficiently and provides clear error messages to the caller for debugging potential issues.
Looking forward to your feedback!

[samlown]

Hi @fabian-z! Many thanks for this PR. This does indeed seem like a better approach compared to Gotenberg. When we tested Chromium PDFs previously we had lots of problems with headers/footers and pagination, but I'll give this a try locally and see how it compares to Prince (our preferred option).

[fabian-z]

Thanks for the feedback! I understand the difficulties and if you have any problematic examples, please feel free to share them with me, will be glad to take a look :) My initial results were comparable with Gotenberg, which also uses Chromium.

Prince indeed seems to have several benefits, but for certain scenarios it makes sense to have a "good enough" and Open Source solution available. In my case, this is due to post processing the PDF with Ghostscript to produce a valid PDF/A-3 hybrid electronic invoice with embedded EN16931 XML.

[samlown]

Agreed, my preference is for a good Open Source solution, which Prince is not. Our own integration with Prince also has support for attaching the XMP data alongside the XML documents (for Factur-X/ZUGFeRD). It's a bit messy though, felt too far detached from the HTML of gobl.html, and is dependent on Prince. We discovered this Python library for attaching data to PDF documents that might be useful for your use-case: https://github.com/akretion/factur-x

…

On Thu, 13 Feb 2025 at 12:55, Fabian Zaremba ***@***.***> wrote: Thanks for the feedback! I understand the difficulties and if you have any problematic examples, please feel free to share them with me, will be glad to take a look :) My initial results were comparable with Gotenberg, which also uses Chromium. Prince indeed seems to have several benefits, but for certain scenarios it makes sense to have a "good enough" and Open Source solution available. In my case, this is due to post processing the PDF with Ghostscript to produce a valid PDF/A-3 hybrid electronic invoice with embedded EN16931 XML. — Reply to this email directly, view it on GitHub <#33 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAADGLTA7NYC4SH6XUAPSBT2PSB4NAVCNFSM6AAAAABXACFHAKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNJWGM3TCOJVGA> . You are receiving this because you commented.Message ID: <invopop/gobl. ***@***.***>

[fabian-z]

Thanks for the pointer to akretion/factur-x, that and the underlying pypdf look very interesting. Will definitely give the library a try. For the moment, I solved the problem directly with Ghostscript, building a solution in PostScript (including XMP) which has the advantage of ensuring PDF/A compliance by built-in validation.. Let me know if that may be interesting for you as well :)