Change default pdf-engine for HTML from wkhtmltopdf to pagedjs-cli?

[jgm]

It seems that wkhtmltopdf has been deprecated (the underlying engine is ancient).

Should we change the default --pdf-engine for HTML to pagedjs-cli?
Or is that just going to cause lots of problems for little gain?

[tarleb]

+1 on changing the default.

My preference would be WeasyPrint, as it's easier to install via package managers. But pagedjs-cli would be a fine choice, too.

[jgm]

I don't know much about the differences between the two. Is there any difference in output quality?

[tarleb]

The approach of paged.js is to provide a kind of polyfill for the CSS print spec, such that all print-CSS instructions get respected. The pagedjs-cli then uses Puppeteer to communicate with the Chromium browser, which then produces the PDF. It's quite sophisticated, good quality, but features very heavy machinery. AFAIK, the only supported installation method is via npm/yarn.

WeasyPrint is a Python program that implements its own rendering engine, just for the purpose of producing PDF. It doesn't require a full browser and is therefore comparatively lightweight. Ubuntu, Debian, brew, etc offer WeasyPrint packages. The alternative is to install it via pip.

Other properties:

	pagedjs-cli	WeasyPrint
license	MIT	BSD-3
CSS support	as great as Chromium	quite good
PDF/UA	no	experimental
last update	3 months ago	5 days ago

[alerque]

As Albert says pagedjs output is going to be superior and it has more capabilities, but the barrier to entry is also much higher. The default HTML renderer should probably be whatever is lowest friction for people to try out. Folks with a stronger preference or willing to invest the setup time can make their own choices anyway. I don't have a dog in the fight because I don't use the HTML/CSS route at all anyway, but weasyprint does seem to make more sense as a default these days than wkhtmltopdf.

[jgm]

Issue here #10142