[styx31]

You are right about the thead repeatable header.

Still, to switch back to the previous point, it seems it's more a divergence between using markup or code to design a document. Both have valid usage and benefits depending on your case.

In my case and my apps, I often need to handle complex conditions that fits better imo in procedural code (complex invoices and agreements). On other cases (reports), I prefer to use a markup language.

[SigmundA]

There are a lot of procedural tools for generating HTML, lots, if modern browsers fully supported print CSS then you could use them for complex PDF generation, or direct printing, either client side or on the server headless.

If your app is a web app this is a no brainer, the users browser could simply do the print or PDF conversion as needed.

I do see a use for more direct libraries in native apps, although if every native client had a browser control with full print CSS support even then it might not be such an issue.

[Scarbutt]

If your app is a web app this is a no brainer, the users browser could simply do the print or PDF conversion as needed.

That's arguable, IME (and also a better UX), most would prefer to just get the PDF file which just one click than to deal with additional browser dialogs. No everyone knows how to do print-to-pdf or even know it exists.

Or do you mean browsers expose print-to-pdf functionality as an API?

[MarcinZiabek]

I am not sure if it is a good idea to think about webpage and PDF content as the same. After all, they both serve different purpose and their layout shouldd be optimized for the use case.