RFC: Use Gotenberg for PDF conversion

[anehx]

Related to #528

Currently we use unoconv / libreoffice with a lot of magic (to make sure processes actually die if neccessary) to convert office documents to a PDF. This works, but we often have issues with certain fonts that are not installed etc. and the whole process magic with isolation is quite complex. Apart from that reasoning, unoconv is long deprecated.

The purpose of DMS is not to be a PDF converter but a template engine. We will never be able to convert perfect PDFs and frankly, shouldn't if there are services that are specialized to do this. I found a nice OSS (MIT license) solution "Gotenberg" which can be deployed as a docker container:

• https://gotenberg.dev/
• https://github.com/gotenberg/gotenberg

There is even a python client for it:

• https://stumpylog.github.io/gotenberg-client/latest/

My proposal would be to remove everything unoconv / libreoffice related from this service in favor of using Gotenberg to convert to PDF.

What do you think?

[martinwe-adfinis]

Given that one of our main pain points is that LibreOffice occasionally hangs up (and unoconv doesn't detect/handle it properly), it would be interesting to see how Gotenberg handles this issue.

[anehx]

Given that one of our main pain points is that LibreOffice occasionally hangs up (and unoconv doesn't detect/handle it properly), it would be interesting to see how Gotenberg handles this issue.

I think this might be handled in their unoconverter script but I'm not quite sure. I think we'd just need to try it out..

[martinwe-adfinis]

It appears the unoconv script in that repo is simply a copy of the unoconv project's unoconv script (+ this change), so it's likely affected by the same problem. Gotenberg itself would need to handle the hang-ups, then.

The Gotenberg documentation on LibreOffice implies two things: it's running LibreOffice in listen mode (implied by the automatic restart after a number of conversions) and it sets a timeout for starting/restarting LibreOffice. But like with unoconv itself, I do not see anything related to timeouts for conversions.

In modules/libreoffice/api/api.go, it appears to start the conversion using some 'supervisor' component (runWithDeadline(), which implies it's following this pattern), but I was unable to see if the context is initialised to timeout for the conversion itself, or only for starting the LibreOffice background process.

I'd be happy for a second pair of (Go-affine) eyes checking the Gotenberg sources, though.

If it does not handle hang-ups for conversions, that's something we'd need to fix upstream (I'm not sure if the workaround we currently have with unoconv—individual/isolated one-shot processes instead of a long-running listener—would even be possible with Gotenberg).