A memory-bounded architecture for bursty HTML-to-PDF workloads
1–5 of 5 posts
Re: A memory-bounded architecture for bursty HTML-to-PDF workloads
#2Generating a PDF with chrome is a far cry away from generating a PDF/A or PDF/UA document.
You pay for what you get.
Re: A memory-bounded architecture for bursty HTML-to-PDF workloads
#3Generating a PDF with chrome is a far cry away from generating a PDF/A or PDF/UA document. You pay for what you get.
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.
Re: A memory-bounded architecture for bursty HTML-to-PDF workloads
#4Generating a PDF with chrome is a far cry away from generating a PDF/A or PDF/UA document. You pay for what you get.
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 an…
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.
Re: A memory-bounded architecture for bursty HTML-to-PDF workloads
#5Earlier quoted context omitted.
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 an…
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.
As already mentioned above, I completely agree with the shortcomings of browsers for PDF conversion. The real fault line, in my opinion, is page-aware engines versus Chrome, and neither side is free. Prince, Antenna House and PDFreactor are built around an actual page model (page breaks, running headers, cross-references, a real TOC), but they're perpetually chasing modern web and CSS support. Chrome is the opposite and weak at the page model. So you either pay for a licensed engine to get the page model, or you take Chrome's rendering and do the page, tagging and conformance work around it. And yes, that means owning the edge cases.