We're looking at doing some HTML to PDF type of stuff for some printed reports. We use Lucee but our front end is react and we use highcharts.js quite a bit. We're exploring new options to see if there is a better way to do this these days (we've used cfdocument, wkhtmltopdf, Phantom.js, etc. in the past). Has anyone looked at https://gotenberg.dev/ before? If not, any other suggestions you'd give?

I'm using https://weasyprint.org/ via command line. Requires python, but can be easily installed in a docker image via

# Weasyprint
RUN apk add py3-pip gcc musl-dev python3-dev pango zlib-dev jpeg-dev openjpeg-dev g++ libffi-dev
RUN apk add fontconfig ttf-freefont font-noto terminus-font \
   && fc-cache -f \
   && fc-list | sort
RUN pip install weasyprint

Then you just feed it html, i.e

weasyprint -u ${this.workingDir} ${htmlDocument.path} ${pdfDocumentPath}

Gotenberg looks interesting, but it really looks like it's just a REST API that just picks different existing PDF engines to use based on the job. If you look at the Dockerfile you can see the PDF engines it installs. I didn't spend a ton of time looking at it, but it looks as if it uses a headless Chromium install for HTML to PDF and then LibreOffice for the other doc formats.

@neokoenig I looked at WeaseyPrint for a minute but the documentation was very specific about it not working with javacscript, so I assumed it wouldn’t work with the React front=end. It looked like you were pointing to an html file rather than a URL. Did I misunderstand that?

@danmurphy Ah right, yeah, we're feeding HTML (or actually, twig templates which then get converted to HTML). I think if you actually want to render Javascript headless if your only route.

If you're already invested in Docker technology, then using Gotenberg seems like a reason approach. It would simplify a lot of things. However, if you're not using Docker that obviously is a change that might be really involved just for HTML-to-PDF integration (depending on how critical PDF generation is to your application). A few years ago I played around with using a headless Chromium for PDF generation, but ended up just using wkhtmltopdf. I can't remember the exact issues at the time, but wkhtmltopdf resolved some issues I would have to deal with manually with Chromium. I wish I could recall what they were. It's also possible the problems are resolved now. It's possible it had to do with the version of Chromium available for us in the OS the project was based too.

Yeah, everything we have already runs in Docker land, so that was appealing about Gotenberg. With wkhtmltopdf, the warnings on the website make me hesitant to use it on a new project at this point. 😬 Am I overreacting? https://wkhtmltopdf.org/status.html#summary

I think it's very reasonable to be concerned. If you have zero knowledge of the HTML/CSS/JS being feed into wkhtmltopdf, it could be an issue. It's not going to work right if you're trying to render HTML docs that based on new features. That's not a concern for our use cases, but at some point I'm sure we will need to upgrade to something that uses a more modern rendering stack. But if you're 99.999% sure that HTML docs that your feeding it are pretty straightforward and would render in a browser like IE11, then wkhtmltopdf should work fine.

Just to report back on this, I like https://gotenberg.dev/ for HTML/URL -> PDF generation. Super easy to get going in a Docker environment, super easy to use. Works well with React.js, Highcharts.js, etc. Really impressed so far. We’re moving forward with it.