Consider switching from weasyprint to another pdf converter

[vincerubinetti]

I noticed that manubot used to use wkhtmltopdf but switched to weasyprint due to the former lacking svg capabilities.

I've just run into a deficiency in weasyprint, in that it doesn't support the CSS calc() value. We don't absolutely need to use the calc() value, at least right now. Conceivably in the future, it could be required to achieve a certain look/layout in a "clean" way compliant with modern best practices.

I'm wary that weasyprint reimplements its own new rendering engine, instead of using a well established standard like webkit or gecko. Even if weasy somehow does basic rendering as good as or better than webkit/gecko (projects that have hundreds of contributors), I think it will necessarily miss some of the more advanced functionality of CSS that we might want/need to use. This calc() value for example isn't exactly a cutting edge CSS feature; it came into being around 2011.

Again, it's a small problem, but it may be worth it to research tools like athena and prince, and see if they're more fully featured (preferably based on webkit) than weasyprint, and would work with pandoc and our build process.

[dhimmel]

Sure happy to consider open source alternatives to weasyprint.

I can't speak regarding the capabilities of athena or prince, but I've been pretty satisfied with the functionality of weasyprint and exceptionally happy with the support. Whenever we report issues, we've responses quickly... even when their not really weasyprint issues.

Not to say we shouldn't evaluate alternatives if there are important missing features. It probably makes sense to revisit this issue more actively if we decide to switch to a manubot Docker image that could more readily include dependencies that are not already part of conda-forge.

[dhimmel]

Random links to look into more:

• https://github.com/RelaxedJS/ReLaXed

[dhimmel]

I tried athenapdf via it's Docker to create a PDF of the bitcoin-whitepaper:

docker run --rm \
  --volume=`pwd`:/converted/ \
  arachnysdocker/athenapdf:2.16.0 \
  athenapdf \
  --delay=2000 \
  https://git.dhimmel.com/bitcoin-whitepaper/v/ebfce2b530b141764275093eee8f424b18144420/

The output was 434d484a41538079696897478e6ff7d532f32871.pdf. It looks great! I had to increase the delay from the default of 200 milliseconds, such that the MathJax equations would finish rendering. Really happy that it was able to convert the equations.

[slochower]

Looks like support for page numbers is still nontrivial. https://github.com/arachnys/athenapdf/issues?utf8=%E2%9C%93&q=numbers

[dhimmel]

We have had good success with Athena for the Meta Review. @slochower also reports success with Athena in greenelab/meta-review#205 (comment).

In greenelab/meta-review@cffcfea, we default to using Athena when available, but fall back to the current WeasyPrint command when Docker is not available. This is one possible implementation.

Another possibility is for us to only build PDFs when Docker is installed and BUILD_PDF!=false. This would allow us to simplify our environment.yml and resolve some frustrating conda dependency incompatibilities we had in #174. PDFs will continue to be built on Travis. This option also prevents two PDFs for the same HTML existing which could get a bit confusing.

Is the ability to create PDFs locally without Docker sufficient to justify the increased support burden of keeping WeasyPrint?

[agitter]

I've encountered a situation where I wanted to build a local PDF on a machine that did not have Docker. Could we adopt the meta-review approach for now and wait until the environment management becomes too burdensome to drop WeasyPrint?

How would two PDFs be built from the same HTML? If a user builds once on a machine with Docker and again on a machine without?

[dhimmel]

How would two PDFs be built from the same HTML? If a user builds once on a machine with Docker and again on a machine without?

Yes, it's a minor issue, but the local PDF may differ from the travis PDF, which could cause some confusion. For example, if we continue to get bug reports about features not working locally due to WeasyPrint.

Could we adopt the meta-review approach for now and wait until the environment management becomes too burdensome to drop WeasyPrint?

Okay.