Support for weasyprint and prince

[mb21]

Rename --latex-engine to --pdf-engine and add support for weasyprint and prince, in addition to wkhtmltopdf

closes #3906

Three remarks/TODOs.

1. In PDF.hs#html2pdf: could we use "program - html2pdf.pdf" to read from stdin instead of using a tempFile? All three HTML-to-PDF-engines support it.

2. It's still a bit counter-intuitive that you have to specify a writer when not using LaTeX, e.g. see:

    $ pandoc -o output.pdf --pdf-engine=weasyprint
    pdf-engine weasyprint is not compatible with format latex, please use `-t html`
   

   I guess we could change the App.hs#defaultWriterName function to depend on the pdf-engine. Then the only question is: why can't I also use context and pdfroff with --pdf-engine?

3. TODO: research and implement best approach to math-handling for weasyprint and prince

[jgm]

Re 1) I'm in favor of using stdin when possible (and also stdout, if we can get the PDF to stdout -- then we wouldn't need any temp files at all).

Re 2) I agree. defaultWriterName for ".pdf" should be sensitive to the pdf-engine selected. Perhaps we should also emit an INFO level log message saying which format had been auto-selected.

[mb21]

finally done. that was somewhat more elaborate than expected, but hopefully it will be a lot easier to add pdf-engines in the future.

[iandol]

You also changed --latex-engine-opt to --pdf-engine-opt?

[mb21]

@iandol jep, arguments specified with --pdf-engine-opt now also get passed to the other pdf-engines...

[iandol]

Can confirm that latest nightly:

pandoc -o Lu.pdf --pdf-engine='prince' --pdf-engine-opt='--page-margin=10mm' Lu.md

Worked as expected. Thank you so much @mb21 for your contribution!

[jgm]

I tested --pdf-engine=prince --mathml and got so-so results. Typesetting isn't as good as LaTeX, by any stretch, and the fonts are often missing needed characters. But you can use any font you like.

[mb21]

jep, probably the way to do it for now is through generating SVGs... e.g. from print-css.rocks:

Brought to the point: MathML support in all renderers is broken at the moment. Lots of formatting and layout issues with native renderers and renderers based on MathJax (Vivliostyle). It is questionable if MathML will ever work. The only future for MathML is a cross-plattform support for a Javascript based rendering engine like MathJax. However neither PrinceXML nor PDFreactor nor Antennahouse support MathJax. So the only recommendation for using MathML directly: forget it. The only valid option is to convert MathML somehow to LaTeX and then SVG. MathML parts of your input should be replaced with a related SVG.

[linquize]

Is latex still the default?

[mb21]

@linquize yes, pdflatex is (for better or worse) still default... (see the updated MANUAL.md)