Forum Bugs

Firefox and Chrome occasionally rendering pdfs as empty pages

AndyF
I've recently noticed that the embedded PDF renderers in Chrome and Firefox will sometimes draw the downloaded pdf file as 'n' empty pages, and other times there will be no problem at all. Firefox reports a 'flate' error in the console when this happens. If you download/save an empty rendered file, then open it with another viewer it will render correctly. The contents that we feed to Prince to generate the PDF are static.

Note that there is another, less frequent failure case that we've seen where the document contains badly rendered text, as though it had defaulted to ascii.

I've experimented a little with the settings here and if I set '--pdf-profile=PDF/A-1b', as opposed to having no pdf profile set, the resulting pdf files are a lot more consistent when checked with a binary diff.

If you could shed any light on this issue or provide any guidance it would be much appreciated.
mikeday
This sounds suspiciously as if the PDF file has been corrupted in some way, as this can cause strange behaviour that differs between PDF viewers. Can you email me (mikeday@yeslogic.com) one of the PDF files which doesn't work properly in Firefox?
AndyF
Since I sent the files, I've had a look into combinations of settings to avoid using encryption. I've found that if I don't use profiles or any of the document copy controls then the PDF won't be generated with any encryption. I'll do some more tests but this configuration looks to me like it may fix the problem.
AndyF
We have recently resolved this issue and thought we should post our findings back to the forum. First let me say that PrinceXML is not at any fault and is producing good PDF files, we’ve verified this on various test servers.

In our old server implementation, we would receive a request and only respond with the result once PrinceXML had finished generating the PDF file. We found that we were taking too long to respond to a request from Chrome, and some other browsers. It was flaky as the amount of time it would take us to serve content could change dramatically, depending on whether we had content cached or not. The fail case would result in a partial pdf file download, so we would still have pdf header content but would be missing a part of the encrypted file body, causing the pdf to render as a number of empty pages.

To resolve the issue, we set the server up to respond immediately using chunked transfer-encoding in the http header. This allows us to send the response header shortly after we receive the response, before we know the size of the content. Chrome is then quite happy to wait whilst the document is generated and transmitted.