support rendering html and docx from extension template

[cameronraysmith]

One of the reasons to use quarto rather than latex directly with the source template is because, via pandoc, it supports generating html, docx, etc alongside pdf or other output formats. ~Although it goes against optimal approaches to using git, since we already vendor the pdf, and the html and docx are smaller in size,~(<-- now irrelevant due to use of CI artifacts in #6) it would be reasonable to illustrate how to generate the html and docx formats ~and vendor them~ along with the pdf.

~A longer-term alternative to this would be to expunge all these artifacts from the git history with git-filter-repo and setup CI to render them as artifacts.~ (<-- now done in #6) This has the advantage that it would also test the rendering process in a uniform environment. See the proposed PR in #6 and the other issue it resolves in #7.

[christopherkenny]

Could you explain a bit of why those types of outputs are useful with a journal template? Do some Nature journals accept HTML or Word files? This is a journal template, which is generally aimed at journal submissions. To my knowledge, those need to be in LaTeX for Springer Nature journals, but I can't claim to know all of the details there.

While these are nice features to have (for example when working with a colleague who does not use LaTeX), I'm not sure if these files are core to what such a template should do. I'm happy to have these documented and for the template to vendor any relevant csl files, but my initial reaction is that these are not typical uses. We do support rendering to those formats and they are currently documented in the README.

I'm happy to hear otherwise if I'm missing something.

[cameronraysmith]

Certainly most people would submit the raw latex and pdf to a preprint server or editor.

When you use quarto, latex is executed via pandoc. Although you can use natbib with pandoc, pandoc provides better support for citeproc. These are the issues and feature support tradeoffs I'm aware of

• some of the citation types generally supported by pandoc do not work with natbib in any output format including ps/pdf
  • This is especially relevant if you're using an author-date-based format. It is one of the reasons we needed to remove some of the examples in https://github.com/christopherkenny/nature/commit/5f26bb42486d02237c70a35a6f73ab16cc9be5e5#diff-aa6a87130eb5f7788d01634591e2e56c8198499e580112cbe73649ce4560d001L87-R77.
  • I agree it is a better idea to make a number-based citation style the default where those examples are not particularly relevant. In #6 I retained the number-based default citation style from citeproc and reintroduced the alternate citation types in code quotes.
• using citeproc with pandoc results in support for rendering essentially equivalent references in html, docx, and pdf formats. If natbib is used as the default, the html and docx may not render or are unlikely to be equivalent to the pdf.
• as you suggest, some fraction of those who would use this template will want to or be required to periodically produce docx for collaborators and may like to post a copy of the manuscript on a self-hosted website.

These could certainly change somewhat as pandoc evolves. Avoiding those issues or supporting those features are advantages of using quarto/pandoc with citeproc. Supporting the uniform rendering of html and docx along with the pdf was the original motivation for https://github.com/christopherkenny/nature/pull/2. https://github.com/christopherkenny/nature/pull/6 now resolves https://github.com/christopherkenny/nature/issues/4 without reverting the citation style to natbib since using citeproc isn't the direct cause of https://github.com/christopherkenny/nature/issues/4. https://github.com/christopherkenny/nature/pull/6 also sets up rendering in CI, which validates the version at the head of the PR branch produces html, docx, and pdf and will help to ensure future changes do not introduce errors that break compilaton. Uploading the various formats as CI artifacts avoids the issue with polluting the git history I mentioned in my original post before I had added the CI workflow to #6.

[cameronraysmith]

I understand this adds some complexity to using the template if your only goal is to have quarto serve as an overlay to pandoc/latex that allows you to render mardown to pdf. I certainly understand if you feel this isn't worth retaining here and am happy to close #5 #6 #7 and maintain the changes from #6 in a detached fork.