Show HN: PlutoPrint – Generate PDFs and PNGs from HTML with Python

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.

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?

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

How does it differ from https://weasyprint.org ?

> 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?

Does anybody have any experience migrating to PlutoPrint from WeasyPrint? Is it seamless? Faster? Any teething issues? Are their reasons to stay with WeasyPrint?

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.

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

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