PrintToPDF: rpcc: message too large

[PrzemoRevolve]

Hello!
I've noticed that when sending a header/footer html files, there seems to be a hard size limit for them.
In case of text this isn't a problem, but I when wanted to embed an inline png as base64 encoded, this caused me a lot of trouble. I ended up converting the PNG to SVG and optimizing it below the limit.

I can't see any entry in the docs that would say how to increase that limit.

Expected Behavior

Either:

1. there should not be a hard limit for header/footer size, or
2. docs should mention how to increase it

Current Behavior

PDF generation fails when header file is too big, with message: "printing page to PDF: cdp.Page: PrintToPDF: rpcc: message too large (increase write buffer size or enable compression)"

Steps to Reproduce (for bugs)

I've created a small reproduction repo with steps & files to reproduce: https://github.com/PrzemoRevolve/gotenberg-header-repro

My Environment

• Version used: I just used docker run --rm -p 3000:3000 thecodingmachine/gotenberg:5
• Operating System and version: Linux Mint 19

[gulien]

Thank you for this well written issue 😄

I need to dig in to understand what's going on. Hopefully I'll be able to provide a fix in version 6.0.0.

[PrzemoRevolve]

@gulien I think this comes from https://github.com/mafredri/cdp/blob/2a28a12ac3f505882ed2648f5a1499ff42d0141b/rpcc/conn.go#L203, where limit: ws.WriteBufferSize, and this WriteBufferSize can come from wsDialer.WriteBufferSize <- maybe this one can be passed as DialOptions to rpcc.DialContext in printer/chrome.go ...?

[LoicHa]

Same here , any idea how to increase the buffer ?
I struggled a lot to insert a decent quality image (base64 src image) in my footer because of this issue..

[LoicHa]

According to chrome dev issue ChromeDevTools/devtools-protocol#24., the buffer has been increased from 1MB to 100 MB. I hope gotenberg 6.0 will get this update too @gulien any plan ? :)

[gulien]

@PrzemoRevolve @LoicHa

Thank you both for your help.

I've increased the buffer size to 1MB and enabled compression (see #121).

I think there is no need to increase even further the buffer size because 1MB compressed is BIG (non-compressed 1MB of text looks like this: https://gist.github.com/khaykov/a6105154becce4c0530da38e723c2330 - I tested an header with this content with success 🎉).

If ok for you, I'll merge #121 and tag a new 6.0.1 release 😄

[PrzemoRevolve]

@gulien Thanks for quickly resolving this problem!
I think 1MB is a safe default, but it would be awesome if you added a possibility to configure this limit, via env variable or process arg - I can see some cases for which it would be useful, e.g. embedding images or font files in header/footer.

[gulien]

@PrzemoRevolve actually we cannot embed Javascript and external resources (fonts, images etc.). The only way to put some images is by using a base64 encoded source (e.g. <img src="data:image/png;base64, iVBORw0K... />.

Still, it could be interesting to provide a way to increase this buffer size, either via an environment variable or via a form field.

[PrzemoRevolve]

@gulien Yes, that's exactly what I meant - as you said only way to do this is with embedding a base64, and this way the size of header/footer could exceed the 1 MB 😄

[gulien]

I've added an env var DEFAULT_GOOGLE_CHROME_RPCC_BUFFER_SIZE and a form field googleChromeRpccBufferSize 😄

See #121

[PrzemoRevolve]

@gulien Thank you! This perfectly solves my case 😁