Disable undesired plugins for Athena pdf print

[vincerubinetti]

Currently, I have a significant amount of CSS, and I believe a few lines of JS, to disable the functionality and appearance of plugins when printing a manuscript. Instead of managing all of these custom styles and such, it seems better to cut things off at the source:

Simply disable all (or almost all? maybe leave mathjax?) plugins by default in the PDF and DOCX config. The plugins are meant for interactive functionality and don't belong there anyway. Then I could get rid of a lot of these unneeded lines, making things easier to maintain. There would also be no question whether the plugins are being disabled/hidden properly; they're not even included at all.

I'm not sure why I didn't do this in the first place. Maybe at first we didn't have separate configs for each output format? If I'm misremembering something that makes this not viable let me know.

Related to: greenelab/covid19-review#1133

[dhimmel]

disable all plugins by default in the PDF and DOCX config

All HTML plugins are activated using Pandoc's include-after-body option. They are only included in the HTML configuration:

rootstock/build/pandoc/defaults/html.yaml

Lines 8 to 26 in 9a22fab

	include-after-body:
	### theme
	- build/themes/default.html
	### first-party plugins
	- build/plugins/core.html # needed for all first-party plugins
	- build/plugins/accordion.html
	- build/plugins/anchors.html
	- build/plugins/attributes.html
	#- build/plugins/inline-svg.html
	- build/plugins/jump-to-first.html
	- build/plugins/lightbox.html
	- build/plugins/link-highlight.html
	- build/plugins/table-of-contents.html
	- build/plugins/tooltips.html
	### third-party plugins
	- build/plugins/analytics.html
	- build/plugins/hypothesis.html
	- build/plugins/mathjax.html
	#- build/plugins/scite.html

So no HTML plugins are applied to DOCX or LaTeX outputs.

Whether they're included in PDF exports depends, since we have two methods for creating PDF: Athena & Weasyprint.

1. With Athena, the default method, we load the HTML output and convert it to PDF as if we printed the page.

2. With Weasyprint, we actually rerun Pandoc, which internally creates HTML and then converts it to PDF with Weasyprint. See the pandoc configuration for this in pdf-weasyprint.yaml

For Athena, all the HTML-activated plugins are activate at print time.

For Weasyprint, since we have a separate Pandoc command, none of the HTML plugins are injected.

I have a significant amount of CSS, and I believe a few lines of JS, to disable the functionality and appearance of plugins when printing a manuscript. Instead of managing all of these custom styles and such, it seems better to cut things off at the source

Printing the webpage directly seems like a somewhat common user flow, so isn't that something we should continue to support? Or perhaps just support when possible unless there is a hard-to-debug issue like greenelab/covid19-review#1133.

Also might we want some plugins to be included in the PDF output. For example the scite badges of citation counts might be nice to show in the references section?

If we want to disable HTML plugins for PDF generation, we'd want to adopt a separate pandoc workflow (like we have with weasyprint).

I think this issue is largely dependent on whether we continue to use Athena for PDF generation. When we first adopted Athena, it solved a lot of issues. However, it is no longer maintained. We've considered switching to paged-js #394 which has some unfixed blockers. Here's the full list of what Pandoc currently supports for pdf-engine: pdflatex, lualatex, xelatex, latexmk, tectonic, wkhtmltopdf, weasyprint, pagedjs-cli, prince, context, and pdfroff. And only a subset go through HTML: wkhtmltopdf, weasyprint, pagedjs-cli, prince (not open source). The pandoc docs mention https://print-css.rocks/.

Summary:

• replacing Athena with a PDF engine supported by pandoc would be helpful here
• plugins should still properly implement CSS Paged Media regardless of whether the manubot PDF generation omits those plugins.

[vincerubinetti]

You're right, we cannot get rid of the print media querying in the CSS. I forgot that people will likely want to be able to print from the HTML manuscript. I wasn't thinking that through.

Regarding the plugins enabled for Athena and Weasy, to me these seem to be the only ones a user could potentially want:

• core (needed for the rest)
• attributes (might do certain essential things like merging to column cells)
• d3 (user might have a dynamically generated figure that they still want a static version of in the PDF)
• mathjax (for equations)
• scite (for badges)

I guess the decision of whether to make a new workflow for Athena or drop it completely is up to you guys. It does make me wary that it's unmaintained, but I'm also not sure paged-js is a good enough alternative yet (it's a very complex problem to solve). But if the source of greenelab/covid19-review#1133 ends up being an Athena bug, then I'd have a stronger recommendation.