A Docker-powered stateless API for PDF files.

Discussed in https://github.com/gotenberg/gotenberg/discussions/440

I deployed new fresh instance on Cloud Run and that's what I got on the first call:

How is that even possible? It wasn't up even for couple of minutes and it's already down?

Same configuration as other instance (just different region, but it shouldn't matter at all). Completely confused, other two instances are working just fine.

P.S. Also, how to restart an instance without redeploying it?

When using gotenberg:7 and the endpoint forms/chromium/convert/html with the additional multipart data pdfFormat=PDF/A-1a the following error ocurred (Convert HTML to PDF/A-1a):

{"level":"error","ts":1664889966.8094878,"logger":"api","msg":"convert HTML to PDF: convert PDF: convert PDF to 'PDF/A-1a' with multi PDF engines: convert PDF to 'PDF/A-1a' with PDFcpu: method not available; convert PDF to 'PDF/A-1a' with PDFtk: method not available; convert PDF to 'PDF/A-1a' with QPDF: method not available; convert PDF to 'PDF/A-1a' with unoconv: unoconv PDF: unix process error: wait for unix process: exit status 5","trace":"a4b50916-7779-4b54-b14a-883469dc98dc","remote_ip":"172.20.0.68","host":"converter:3000","uri":"/forms/chromium/convert/html","method":"POST","path":"/forms/chromium/convert/html","referer":"","user_agent":"ReactorNetty/1.0.17","status":500,"latency":2274155848,"latency_human":"2.274155848s","bytes_in":-1,"bytes_out":21}

Especially the part: convert PDF to 'PDF/A-1a' with unoconv: unoconv PDF: unix process error: wait for unix process: exit status 5

This happened using a gotenberg container, which was running for about 3 weeks in total. I guess the unoconv-service / listener failed / crashed and didn't recover? Either way, this shouldn't be the case I guess.

Cloud Run is a managed compute platform that automatically scales your stateless containers. Cloud Run is serverless: it abstracts away all infrastructure management, so you can focus on what matters most — building great applications

Anyone tried Gotenberg on Cloudrun? Im assuming it would work as its stateless? Could have huge cost savings...

It would be great to have some way to generate PDF files from HTML with a transparent background.

It should be possible by setting Emulation.setDefaultBackgroundColorOverride in Puppeteer as stated here: https://github.com/puppeteer/puppeteer/issues/2545#issuecomment-423454635

Is there any way to archive this with gotenberg?

Every so often, the latest 7.5 docker image will crash on startup. Here's the docker logs:

pdfgen_1     | 
pdfgen_1     |   _____     __           __               
pdfgen_1     |  / ___/__  / /____ ___  / /  ___ _______ _
pdfgen_1     | / (_ / _ \/ __/ -_) _ \/ _ \/ -_) __/ _ '/
pdfgen_1     | \___/\___/\__/\__/_//_/_.__/\__/_/  \_, / 
pdfgen_1     |                                    /___/
pdfgen_1     | 
pdfgen_1     | A Docker-powered stateless API for PDF files.
pdfgen_1     | Version: 7.5.0
pdfgen_1     | -------------------------------------------------------
pdfgen_1     | [SYSTEM] modules: api chromium gc libreoffice logging pdfcpu pdfengines pdftk prometheus qpdf uno uno-pdfengine webhook 
pdfgen_1     | [SYSTEM] gc: application started
pdfgen_1     | [SYSTEM] api: server listening on port 3000
pdfgen_1     | [SYSTEM] prometheus: collecting metrics
pdfgen_1     | [SYSTEM] pdfengines: pdfcpu pdftk qpdf uno-pdfengine
pdfgen_1     | [FATAL] starting uno: start long-running LibreOffice listener: waiting for the LibreOffice listener socket to be available: context deadline exceeded

Is this a timeout issue? I don't believe the previous docker image (7.4.3) had this issue.

We recently switched from AthenaPDF to Gotenberg, as AthenaPDF is unmaintained. We noticed a significant increase of file size in the generated PDFs. This unfortunately broke our integration with other tools, which enforce a file size limit for our PDFs.

I noticed this was reported before (#479), but the suspected issue ("I suspect it has something to do with images that are being repeated on every page, like in a header for example.") is incorrect.

When run using the demo instance of Gotenberg, using the "https://sparksuite.github.io/simple-html-invoice-template/" test input from the docs:

| Tool | File size | File | | --- | --- | --- | | Gotenberg | 104 KB | gotenberg-1.pdf | | Chromium | 85 KB | chromium-1.pdf | | AthenaPDF | 60 KB | athenapdf-1.pdf | | Firefox | 33 KB | firefox-1.pdf |

I don't have any knowledge about the PDF format nor communicating with Chromium instances, so I'm afraid I can't really help debugging this further.

https://github.com/gotenberg/gotenberg/blob/main/build/Dockerfile.cloudrun seems like it should work out of the box, but it's not.

Getting this error: terminated: Application failed to start: Failed to create init process: failed to load /usr/bin/tini: exec format error

What can I do about it?

We are currently using a Libreoffice + unoconv + api (node) architecture to generate our PDF, and we are considering switching to the more recent, maintained and beautifully coded Gotenberg ;) but we noticed some performance drawbacks.

The doc says It starts a dedicated LibreOffice instance for each request.. This seems to add about 2 to 3s to the generation time, vs. our current architecture where the Libreoffice instance is just constantly idling, waiting for a new request (unoconv in listener mode).

3 additional seconds per conversion feels quite like a long time =/ Is there any way to improve that? Do you envision an option in the future to keep the LibreOffice open for longer than one request?

Also, it says It starts a dedicated LibreOffice instance for each REQUEST but according to our preliminary tests, it seems like it does it for every conversion, not every request : if we make a request with multiple files to convert (and merge), the conversion time seems to just be linear with the number of docs (vs. our expectation of faster conversion for subsequent files once the LibreOffice instance is started for the first one). Do you confirm that's what is happening?

On the Live Demo, the unoconv listener process did become a zombie for some reason.

While unoconv is still working (it creates a dedicated LibreOffice instance in such a scenario), the conversions are way slower.

In order to prevent this from happening, we have to:

1. Check the state of the unoconv listener process.
2. If state is invalid (no such process / zombie), try to restart the listener.
3. If restart fails, /health endpoint should return an error.

I never programmed in Go before, so I don't clearly understand what I am doing.

This PR aims to add QPDF as a tool to merge PDFs, because it can deal with invalid PDFs files, which PDFtk can not do.

Also, I think that would be cool if Gotenberg have another tool on it.

dotx is supported by Libre Office. I can open these files using LibreOffice 4.4.1.2.

but not listed at supported extensions here https://gotenberg.dev/docs/modules/libreoffice#route

Pls support .dotx and .xltx

Hi, this is more a general feature request and maybe something that should be opened in the PDF engine repos so please feel free to close if inappropriate.

I was wondering if it would be possible to add emails (.eml) as a supported file format. There is just no tool that can convert emails currently, so would be really helpful.

Thanks :)

Hello

Is possible to detect non 200 status of the requested URL page when use chromium processer ?

$response = Gotenberg::send($pdf);
$response->getStatusCode() // Get the API status code, not the URL used to generate pdf file

Thanks

When webhooks are used, it is difficult to manage the total number of requests being processed. Even when our system uses an event queue to submit requests, we'd have to await the webhook completion. In my case, the webhook posts to an AWS S3 URL, so the event queue would have to await the S3 hook.

This PR adds an option to limit the number of active instances that can exist simultaneously.

I'm not experienced in go, so the code may not be good quality. I also did not create any tests.

Hey guys. I'm trying to create a pdf of a page that contains webgl content (a map with some stuff on top of it)

It doesn't work with the normal current flags. I'm getting

trimblemaps-3.4.0.js:35 Error: Failed to initialize WebGL

I've checked chrome://gpu and WebGL WebGL2 is disabled. (I've set the headless flag to false so i could see the window through xquartz and debug easier)

I've opened an issue on chromedp because I initially assumed it was on their side

Made a playground to experiment different flags (mainly --use-gl & --use-angle). https://github.com/robiXxu/chromedp-playground

The goal was to get WebGL working with swiftshader (since gotenberg is running in a docker container and don't have access to a gpu)

A contributer (Zekelu) pointed in the right direction and I was able to render webgl content inside my playground

I tried to do the same thing in gotenberg however I'm not able to get webgl supported with the same flags.

I assumed that we need to install something and tried including mesa-utils & related packages in the Dockerfile as it was sugested by people on other packages which encountered the same issue ( eg https://github.com/DevExpress/testcafe/issues/2116 , https://github.com/accetto/headless-drawing-g3/blob/master/docker/xfce/README.md#using-openglwebgl-and-hw-acceleration )

    apt-get install cmake pkg-config mesa-utilslibglu1-mesa-dev freeglut3-dev mesa-common-dev libglew-dev libglfw3-dev libglm-dev libao-dev libmpg123-dev -y &&\

But after a lot of trial and error I've figured that it might be time to open an issue and ask others if they found themselves in the same situation and how they overcome it?