If PDF in your app is just another format, such as a downloadable invoice or some printable data tables, and if you’re willing to compromise on pixel perfection, then HTML to PDF generation via wkhtmltopdf (or a more modern alternative) is hard to beat in terms of simplicity (OK, except maybe File > Print > Save as PDF 🤓). So which option is best? The answer is, of course, that it depends! These services take all the headache out of the process, but, as with all third-party services, you’ll need to consider data security and uptime requirements. Two of the leading ones for PDFs that also have Ruby libraries are DocRaptor and BreezyPDF. There is an increasing number of web services that will handle your PDF (and other document) creation and processing needs for a price. As a generic HTML/CSS renderer, it can also output other formats. While it only supports CSS 2, with 10 years of development behind it, you can be fairly sure it handles all the edge cases. via JRuby), another solid option for HTML to PDF rendering is Flying Saucer. This post documents rolling your own similar solution using Puppeteer to control headless Chrome. pdf-bot manages a job queue and sends a webhook to notify us when our PDF is ready. Where we might have shelled out to a CLI, we can instead post to an API endpoint. If you’re willing to look further afield, there are many non-Ruby options, two of which we’ll highlight here.įor fans of microservices, a modern take on the wkhtmltopdf approach is pdf-bot, a Node library for generating PDFs from HTML using headless Chrome.
#RAILS PDFKIT LICENSE#
HexaPDF is open source (AGPL), but it requires a license for commercial use. Similar to wkhtmltopdf, it also ships with a CLI that’s handy for batch processing documents. Reviewing the API documentation, it’s clear that HexaPDF delves deep to handle some of the more arcane aspects of working with PDFs. Our “Hello, World!” example using Prawn couldn’t be much simpler: Instead, it can be thought of as a builder-like DSL for creating and manipulating PDFs, similar to what Jbuilder is to JSON. Prawn clearly states that it is not an HTML to PDF generator. This would very often result in timeouts if not using a background job. In my own experience, a major drawback was high memory usage, even when rendering relatively modest multi-page documents.
There are other issues with wkhtmltopdf you might want to consider.
#RAILS PDFKIT TRIAL#
These can be difficult to debug without resorting to good old trial and error. The downside of this approach is that PDF is not the DOM, so rendering issues do occur. In addition, gems such as Wicked PDF and PDFKit (no relation 🤭) provide a friendly Ruby wrapper around wkhtmltopdf to simplify usage and integration with Rails. The obvious win here is that there’s nothing new to learn, you can write your PDFs in HTML and CSS, and you can even reuse your existing views and partials (e.g.
0 kommentar(er)
