Maybe this isn't the same but it's a relatively few lines of code to use puppeteer to use an actual browser to render pages to PDFs/PNGs. Advantages would be everything is supported. Every new feature in CSS, HTML, SVG, Canvas2D, WebGL, WebGPU, etc... (though for WebGL/WebGPU you might need to pass in some flags to use llvmpipe/mesa/warp etc...
Asking your favorite LLM will give you da codez
PS: I'm not trying to discount this tool. I'm only pointing out an alternative that might be useful
That’s a good point. Using Puppeteer or a headless browser gives you essentially full web platform support. The tradeoff is that it comes with a heavier runtime and more moving parts (Chromium, Node, etc.). PlutoPrint aims to be much lighter: no browser dependency, just a compact C++ engine with a Python wrapper. It does not cover the entire browser feature set but it is fast, portable, and easy to drop into projects without the overhead of a full browser.
We're doing a very similar thing (custom lightweight engine) over at https://github.com/DioxusLabs/blitz. We have more of a focus on UI, but there's definitely overlap (we support rendering to image, but don't have pagination/fragmentation implemented).
Have you run the WPT tests against your engine to test spec conformance?
Exactly what I was wondering. I use puppeteer to render these [1] printable puzzles pages, and I use SVG, JavaScript to dynamically resize the text to fit a page, etc. Just works.
WeasyPrint is great, but PlutoPrint takes a different angle: the engine is all C++, so it’s faster and lighter on memory. It can render directly to PNG as well as PDF, and has stronger SVG support.
This isn't theoretical. In my 20 years in retail and logistics, I've seen these libraries repeatedly fail in production. Real world examples include:
* Invoices: Totals get pushed to a new page with no repeated <thead> header. This is a classic failure of CSS table rendering across page breaks. properties like page-break-inside: avoid are notoriously inconsistent in browser print to PDF engines. Line items get split mid row because the engine doesn't understand the semantic integrity of the data.
* Bills of Lading & Manifests: These documents are infamous for unpredictable page breaks. One page cuts a row in half, the next duplicates headers, the next drops content entirely. This often stems from complex flexbox or grid layouts that the PDF rendering engine struggles to paginate deterministically.
* Shipping Labels: A barcode or QR code shifting by a few pixels is often a DPI or scaling artifact. The browser rendering at a logical 96 DPI doesn't translate perfectly to a 300 or 600 DPI thermal printer format, introducing rounding errors that are catastrophic for scanners. Addresses drift outside the printable area because CSS margins (margin, padding) can be interpreted differently by the print media engine versus the screen engine.
* Digital Forms: This is a classic failure of absolute vs. relative positioning. When you overlay HTML form fields on a scanned PDF background (a common requirement), the HTML box model's flow layout simply cannot guarantee pixel-perfect alignment with the fixed grid of the underlying image. I've seen teams resort to printing, using white out, and hand filling forms because the software couldn't align (x, y) coordinates.
* Tickets & Passes: Scanner rejection due to incorrect sizing is often due to the browser engine's "print scaling" or "fit-to-page" logic, which can be difficult to disable and varies between environments (e.g., a local Docker container vs. an AWS Lambda function with different system fonts or libraries installed).
This always turns into a long tail of support tickets. The only truly reliable solution is to bypass the HTML/CSS rendering model entirely and build the document on a canvas with an absolute coordinate system. This means using libraries like FPDF (PHP), ReportLab (Python), or lower-level tools like iText/PDFBox (Java), where you aren't "converting" a document, you are drawing it. You place text at (x, y), draw a line from (x1, y1) to (x2, y2), and manage page breaks and object placement explicitly.
It's not cheap. The initial build cost is high because every layout is effectively a small, “programmaticd CAD project”. You can't just "throw HTML at it". But the payoff in reliability is immense. It becomes a set and forget system that produces identical documents every time, which stops the endless firefighting.
Yes, two years later it can be painful to update when the original developer is gone. But I would take that trade off any day over constantly battling with imprecise, non deterministic tools. In twenty years of building systems where documents are mission critical, "close enough" rendering was almost never good enough.
Does anybody have any experience migrating to PlutoPrint from WeasyPrint? Is it seamless? Faster? Any teething issues? Are their reasons to stay with WeasyPrint?
I’m also looking at this as a replacement for wkhtmltopdf as well. I had reimplemented with Puppeteer, but it’s very ram heavy for the 200-500 page PDFs I generate. I’m hoping this renders what I need properly.
It would be great if you could run it against the tests at https://www.print-css.rocks/
They would give a much better idea of its complex printing capabilities.
It should be required to run these tests for these libraries. It's really frustrating to have to discover it trying to make it work.
This is so efficient, i just tested it ,far better than weasyprint, and it has both python and c++ repo, bro am amazed, Are you open for sponsorship?
What OS did you test on? It completely crashed my python process on mac
Maybe this isn't the same but it's a relatively few lines of code to use puppeteer to use an actual browser to render pages to PDFs/PNGs. Advantages would be everything is supported. Every new feature in CSS, HTML, SVG, Canvas2D, WebGL, WebGPU, etc... (though for WebGL/WebGPU you might need to pass in some flags to use llvmpipe/mesa/warp etc...
Asking your favorite LLM will give you da codez
PS: I'm not trying to discount this tool. I'm only pointing out an alternative that might be useful
That’s a good point. Using Puppeteer or a headless browser gives you essentially full web platform support. The tradeoff is that it comes with a heavier runtime and more moving parts (Chromium, Node, etc.). PlutoPrint aims to be much lighter: no browser dependency, just a compact C++ engine with a Python wrapper. It does not cover the entire browser feature set but it is fast, portable, and easy to drop into projects without the overhead of a full browser.
Interesting. I was not aware of PlutoBook!
We're doing a very similar thing (custom lightweight engine) over at https://github.com/DioxusLabs/blitz. We have more of a focus on UI, but there's definitely overlap (we support rendering to image, but don't have pagination/fragmentation implemented).
Have you run the WPT tests against your engine to test spec conformance?
Exactly what I was wondering. I use puppeteer to render these [1] printable puzzles pages, and I use SVG, JavaScript to dynamically resize the text to fit a page, etc. Just works.
[1]: https://ahapdf.nyc3.cdn.digitaloceanspaces.com/samplers/logi... (PDF)
How does it differ from https://weasyprint.org ?
WeasyPrint is great, but PlutoPrint takes a different angle: the engine is all C++, so it’s faster and lighter on memory. It can render directly to PNG as well as PDF, and has stronger SVG support.
PlutoBook looks very impressive. Is it based on another renderer?
> book.load_url("input.html")
Shouldn’t this be a URL like https://example.com
Also, is there support for creating a linkable table of contents?
This isn't theoretical. In my 20 years in retail and logistics, I've seen these libraries repeatedly fail in production. Real world examples include:
* Invoices: Totals get pushed to a new page with no repeated <thead> header. This is a classic failure of CSS table rendering across page breaks. properties like page-break-inside: avoid are notoriously inconsistent in browser print to PDF engines. Line items get split mid row because the engine doesn't understand the semantic integrity of the data.
* Bills of Lading & Manifests: These documents are infamous for unpredictable page breaks. One page cuts a row in half, the next duplicates headers, the next drops content entirely. This often stems from complex flexbox or grid layouts that the PDF rendering engine struggles to paginate deterministically.
* Shipping Labels: A barcode or QR code shifting by a few pixels is often a DPI or scaling artifact. The browser rendering at a logical 96 DPI doesn't translate perfectly to a 300 or 600 DPI thermal printer format, introducing rounding errors that are catastrophic for scanners. Addresses drift outside the printable area because CSS margins (margin, padding) can be interpreted differently by the print media engine versus the screen engine.
* Digital Forms: This is a classic failure of absolute vs. relative positioning. When you overlay HTML form fields on a scanned PDF background (a common requirement), the HTML box model's flow layout simply cannot guarantee pixel-perfect alignment with the fixed grid of the underlying image. I've seen teams resort to printing, using white out, and hand filling forms because the software couldn't align (x, y) coordinates.
* Tickets & Passes: Scanner rejection due to incorrect sizing is often due to the browser engine's "print scaling" or "fit-to-page" logic, which can be difficult to disable and varies between environments (e.g., a local Docker container vs. an AWS Lambda function with different system fonts or libraries installed).
This always turns into a long tail of support tickets. The only truly reliable solution is to bypass the HTML/CSS rendering model entirely and build the document on a canvas with an absolute coordinate system. This means using libraries like FPDF (PHP), ReportLab (Python), or lower-level tools like iText/PDFBox (Java), where you aren't "converting" a document, you are drawing it. You place text at (x, y), draw a line from (x1, y1) to (x2, y2), and manage page breaks and object placement explicitly.
It's not cheap. The initial build cost is high because every layout is effectively a small, “programmaticd CAD project”. You can't just "throw HTML at it". But the payoff in reliability is immense. It becomes a set and forget system that produces identical documents every time, which stops the endless firefighting.
Yes, two years later it can be painful to update when the original developer is gone. But I would take that trade off any day over constantly battling with imprecise, non deterministic tools. In twenty years of building systems where documents are mission critical, "close enough" rendering was almost never good enough.
Does anybody have any experience migrating to PlutoPrint from WeasyPrint? Is it seamless? Faster? Any teething issues? Are their reasons to stay with WeasyPrint?
Comparing it to typst ?
Does this support full flexbox styling?
What are the known issues or the unsupported css this library has?
Might need this wkhtmltopdf being bound to bookworm
I’m also looking at this as a replacement for wkhtmltopdf as well. I had reimplemented with Puppeteer, but it’s very ram heavy for the 200-500 page PDFs I generate. I’m hoping this renders what I need properly.
for a second I thought it's this Pluto (note)book https://plutojl.org/
Nice! I think that it would be great if this could take markdown as input, without having to convert to HTML first