A memory-bounded architecture for bursty HTML-to-PDF workloads

https://adrianani.com/articles/html-to-pdf-api-blueprint

by adrianani-com • 10 days ago

3 4 10 days ago

adrianani.com

sscaryterry2• 10 days ago

Generating a PDF with chrome is a far cry away from generating a PDF/A or PDF/UA document.

You pay for what you get.

to21as2• 9 days ago

Yes, exactly. Chrome doesn't support PDF generation very well when it comes to details. In fact, Chrome doesn't really have a concept of pages at all — which comes with all kinds of related limitations: page break issues, running headers, cross references, table of contents, etc. Despite that, Chrome still became the de facto HTML-to-PDF engine.

Getting a PDF/A or PDF/UA conforming file out of it is tedious indeed and requires quite a bit of extra work — tagging the DOM before the render, then post-processing the output (fixing link annotations, stamping XMP conformance metadata, etc.). This is actually exactly what we did for polydoc.tech (https://polydoc.tech). The basic architecture described in the article is close to what we run too. Disclosure: I'm the founder of polydoc.tech.

sscaryterry2• 9 days ago

If you’re post-processing and relying on a browser to do the actual work, you will suffer death by a thousand little cuts.

You have no company information, the compliance documents are all vibed, shameless plugs like this where you are no better is rude.

A memory-bounded architecture for bursty HTML-to-PDF workloads

Related Stories