to21as

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.

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.