A Docker-powered stateless API for PDF files.

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.

Hi

Is there any way to support a proxy server for the chromium module? I have tried setting the system proxy, but that doesn't seem to do the trick. So there's still the --proxy-server flag for chromium but I guess that's not supported, is it?

When I send a significantly large payload of HTML (about 800kb) that contains a lot of images (say ~3-4 per page, 250 pages in total) - rendering fails with the following error message:

{
    "level": "error",
    "msg": "cdp.Page: PrintToPDF: rpc error: Printing failed (code = -32000)",
    "op": "xhttp.htmlHandler: xhttp.convertSync: printer.chromePrinter.Print",
    "time": "2020-09-22T18:04:50Z",
    "trace": "s1azQwaNSYBE6zK3y5R7VhstCYbPtrix"
}

and

{
    "level": "debug",
    "msg": "[0922/180450.372244:ERROR:print_render_frame_helper.cc(1889)] Printing failed.",
    "op": "stderr.google-chrome-stable.--no-sandbox.--headless.--disable-dev-shm-usage.--font-render-hinting=none.--remote-debugging-port=9222.--disable-gpu.--disable-translate.--disable-extensions.--disable-background-networking.--safebrowsing-disable-auto-update.--disable-sync.--disable-default-apps.--hide-scrollbars.--metrics-recording-only.--mute-audio.--no-first-run",
    "time": "2020-09-22T18:04:50Z",
    "trace": "system"
}

Is there anything I can do / tweak in the environment variables to mitigate this? I've already increased the RPC buffer without success. System is running on AWS Fargate, 2vCPUs, 8GB of RAM.

Expected Behavior

Rendered document is returned.

Current Behavior

Rendering fails with HTTP 500.

Your Environment

• Version used: 6.3.0
• Operating System and version: Docker container running on AWS Fargate 2/8GB

I noticed that sending the post request with file that has 150 344 bytes is slow. In my local enviroment I takes about 4 sec to get the Response. In my production enviroment I takes about 40 sec! We use python request library and we send just the attached file to the server. Do we need to use some extrat options to zip the html file or sth?

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?

On Gotenberg 7.7.0, generating PDF from The Chromium module (url, html, markdown) time out with 503 Service Unavailable.

With debug log I get these errors:

{"level":"debug","ts":1668185919.5321708,"logger":"api.formschromiumconverturl","msg":"form data values: map[paperHeight:[11.7] paperWidth:[8.27] url:[https://gotenberg.dev/]]","trace":"debug"}
{"level":"debug","ts":1668185919.532192,"logger":"api.formschromiumconverturl","msg":"form data files: map[]","trace":"debug"}
{"level":"debug","ts":1668185919.6312675,"logger":"api.formschromiumconverturl.browser","msg":"[1111/165839.631183:ERROR:bus.cc(399)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory\n","trace":"debug"}
{"level":"debug","ts":1668185919.6318676,"logger":"api.formschromiumconverturl.browser","msg":"[1111/165839.631824:ERROR:bus.cc(399)] Failed to connect to the bus: Failed to connect to socket /run/dbus/system_bus_socket: No such file or directory\n","trace":"debug"}
{"level":"debug","ts":1668185919.6348476,"logger":"api.formschromiumconverturl.browser","msg":"[1111/165839.633642:WARNING:bluez_dbus_manager.cc(247)] Floss manager not present, cannot set Floss enable/disable.\n","trace":"debug"}
{"level":"debug","ts":1668185919.636943,"logger":"api.formschromiumconverturl.browser","msg":"[1111/165839.636439:ERROR:gpu_init.cc(521)] Passthrough is not supported, GL is disabled, ANGLE is \n","trace":"debug"}
{"level":"debug","ts":1668185919.6375313,"logger":"api.formschromiumconverturl.browser","msg":"\n","trace":"debug"}
{"level":"debug","ts":1668185919.6375408,"logger":"api.formschromiumconverturl.browser","msg":"DevTools listening on ws://127.0.0.1:44411/devtools/browser/5c309783-b2da-4b8a-81cf-accd105e41a0\n","trace":"debug"}
{"level":"debug","ts":1668185919.6377795,"logger":"api.formschromiumconverturl.browser","msg":"","trace":"debug"}
{"level":"debug","ts":1668185919.6409626,"logger":"api.formschromiumconverturl.browser","msg":"-> {\"id\":1,\"method\":\"Target.setDiscoverTargets\",\"params\":{\"discover\":true}}","trace":"debug"}
{"level":"debug","ts":1668185919.6417055,"logger":"api.formschromiumconverturl.browser","msg":"<- {\"method\":\"Target.targetCreated\",\"params\":{\"targetInfo\":{\"targetId\":\"6658109268078935153E6B4759D6D629\",\"type\":\"page\",\"title\":\"\",\"url\":\"about:blank\",\"attached\":false,\"canAccessOpener\":false,\"browserContextId\":\"C83704CF3CF4D586EC5D369387C6C6D7\"}}}","trace":"debug"}
{"level":"debug","ts":1668185919.6417406,"logger":"api.formschromiumconverturl.browser","msg":"<- {\"id\":1,\"result\":{}}","trace":"debug"}
{"level":"debug","ts":1668185919.6417603,"logger":"api.formschromiumconverturl.browser","msg":"-> {\"id\":2,\"method\":\"Target.attachToTarget\",\"params\":{\"targetId\":\"6658109268078935153E6B4759D6D629\",\"flatten\":true}}","trace":"debug"}
{"level":"debug","ts":1668185919.6432273,"logger":"api.formschromiumconverturl.browser","msg":"<- {\"method\":\"Target.targetInfoChanged\",\"params\":{\"targetInfo\":{\"targetId\":\"6658109268078935153E6B4759D6D629\",\"type\":\"page\",\"title\":\"\",\"url\":\"about:blank\",\"attached\":true,\"canAccessOpener\":false,\"browserContextId\":\"C83704CF3CF4D586EC5D369387C6C6D7\"}}}","trace":"debug"}
{"level":"debug","ts":1668185919.6433818,"logger":"api.formschromiumconverturl.browser","msg":"<- {\"method\":\"Target.attachedToTarget\",\"params\":{\"sessionId\":\"3BC75A57721FE009AAB783A858640936\",\"targetInfo\":{\"targetId\":\"6658109268078935153E6B4759D6D629\",\"type\":\"page\",\"title\":\"\",\"url\":\"about:blank\",\"attached\":true,\"canAccessOpener\":false,\"browserContextId\":\"C83704CF3CF4D586EC5D369387C6C6D7\"},\"waitingForDebugger\":false}}","trace":"debug"}
{"level":"debug","ts":1668185919.6433961,"logger":"api.formschromiumconverturl.browser","msg":"<- {\"id\":2,\"result\":{\"sessionId\":\"3BC75A57721FE009AAB783A858640936\"}}","trace":"debug"}
{"level":"debug","ts":1668185919.6434402,"logger":"api.formschromiumconverturl.browser","msg":"-> {\"id\":3,\"sessionId\":\"3BC75A57721FE009AAB783A858640936\",\"method\":\"Runtime.enable\"}","trace":"debug"}
{"level":"debug","ts":1668185919.7340097,"logger":"api.formschromiumconverturl.browser","msg":"<- {\"method\":\"Inspector.targetCrashed\",\"params\":{},\"sessionId\":\"3BC75A57721FE009AAB783A858640936\"}","trace":"debug"}
{"level":"debug","ts":1668185919.7341862,"logger":"api.formschromiumconverturl.browser","msg":"<- {\"method\":\"Target.targetCrashed\",\"params\":{\"targetId\":\"6658109268078935153E6B4759D6D629\",\"status\":\"crashed\",\"errorCode\":133}}","trace":"debug"}
{"level":"debug","ts":1668185979.5318904,"logger":"api.formschromiumconverturl","msg":"remove user profile directory '/tmp/ca79538a-3178-428c-a90c-fa115d5bd687'","trace":"debug"}
{"level":"debug","ts":1668185979.548903,"logger":"api.formschromiumconverturl","msg":"'/tmp/1156399b-177e-4846-9fad-f109bfdb00cd' removed","trace":"debug"}
{"level":"error","ts":1668185979.5489373,"logger":"api","msg":"convert URL to PDF: convert to PDF: chromium PDF: context deadline exceeded","trace":"debug","remote_ip":"77.236.206.138","host":"10.0.0.112","uri":"/forms/chromium/convert/url","method":"POST","path":"/forms/chromium/convert/url","referer":"","user_agent":"PostmanRuntime/7.29.2","status":503,"latency":60017469853,"latency_human":"1m0.017469853s","bytes_in":407,"bytes_out":19}

Other modules are ok :slightly_smiling_face:

The container is running on arm64, 4 CPU, 24GB RAM server.

I will be grateful for any help

Hi all,

I have styling issue with the weird dots on table of content for converting word to pdf from LibreOffice through Gotenberg.

Gotenberg version:

LibreOffice Headless conversion:

Issues:

• There is no dot in the original word document however gotenberg conversion is printing dot
• No page number showing on the gotenberg version but it is showing on the direct conversion from libreoffice headless through CLI

Please let me know if I am missing something.

Thank you.

Hi,

From early 2021, AWS lambda supports docker based deployment which supports upto 10GB in container image size.

https://aws.amazon.com/blogs/aws/new-for-aws-lambda-container-image-support/

Do you have a plan to support lambda based deployment using docker in the future releases?

I started the application in kubernetes with this manifest:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: file-convert-service-gotenberg-deployment
  labels:
    name: file-convert-service-gotenberg
spec:
  replicas: 1
  selector:
    matchLabels:
      app: gotenberg
  template:
    metadata:
      labels:
        app: gotenberg
    spec:
      containers:
        - name: gotenberg
          securityContext:
            privileged: false
            runAsUser: 1001
          image: "dreg.example.com/dockerhub/gotenberg/gotenberg:7.7.0"
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 3000
              protocol: TCP
          livenessProbe:
            httpGet:
              path: health
              port: http
          readinessProbe:
            httpGet:
              path: health
              port: http
          resources:
            limits:
              cpu: 500m
              memory: 512Mi
            requests:
              cpu: 500m
              memory: 512Mi

if the application is idle for a couple of minutes, then the first conversion attempts will be unsuccessful, a 500 error will be thrown, and such an entry in the logs:

{"level":"error","ts":1667816697.079552,"logger":"api","msg":"convert to PDF: unoconv PDF: unix process error: wait for unix process: exit status 5","trace":"cff58268-fc06-412b-b76c-9c67e3941c78","remote_ip":"10.99.145.2","host":"file-convert-service/example.com","uri":"/forms/libreoffice/convert","method":"POST","path":"/forms/libreoffice/convert","referer":"","user_agent":"curl/7.79.1","status":500,"latency":446446326,"latency_human":"446.446326ms","bytes_in":100566,"bytes_out":21}

after that, I keep trying, every second after an unsuccessful response, and the code 500 is returned to me 7-8 more times. after that the conversion is successful. how can i fix this? maybe I should disable unnecessary modules? or something else to tweak?