PDF not rendering at all: getOperatorList - ignoring errors during task: RenderPageRequest

[ndnenkov]

This can be reproduced either with a simple app using PDFJS or a newer version of Firefox. I'll give details for the latter.

Attach (recommended) or Link to PDF file here:
not-shown-pdfjs.pdf

Configuration:

- Web browser and its version:
Firefox 57.0.1 (64-bit)
- Operating system and its version:
OS X EI Capitan 10.11.6
- PDF.js version:
1.9.583 (shipped with Firefox)
- Is a browser extension:
No (built into Firefox out of the box)

Steps to reproduce the problem:

1. Open the related PDF

What is the expected behavior? (add screenshot)
One page with the text 'Test' is rendered. Works with any other viewer I tried.

What went wrong? (add screenshot)
Nothing renders.

Related warning in the console:

Warning: getOperatorList - ignoring errors during task: RenderPageRequest: page 0

[Snuffleupagus]

This is what the content stream in that PDF file looks like, once decoded:

q
BT
/F1 15 Tf
. .59 .84 rg
50 750 Td
(Test) Tj
ET
Q

The rg, i.e. the "setFillRGBColor", operator requires three numerical arguments. However as can be seen above (in . .59 .84 rg), the first value is just a decimal comma which obviously isn't a valid number.

[ndnenkov]

@Snuffleupagus I see. So is it a matter of adding a sensible default when the value isn't numeric (0 perhaps)? Is this going to get fixed in PDFJS?

[Snuffleupagus]

So is it a matter of adding a sensible default when the value isn't numeric (0 perhaps)?

I don't completely understand this question, since if you're not providing three numeric arguments then the rg operator, and by extension the PDF file itself, is not valid. So obviously, if you want one of the values to be zero, then it should be set to that (and not to something else).

Is this going to get fixed in PDFJS?

It may eventually get fixed, but please keep in mind that this is a bug in a specific PDF file, rather than in the PDF.js library itself. And in this case, I'm not sure if there's an easy solution that won't slow down parsing of valid PDF files.
Hence a workaround may not be implemented any time soon, so if you're in control of the PDF generation, please make sure that the file created is valid.

[ndnenkov]

I understand that it's not valid. My point was that other viewers seem to use 0 when a value is not valid (numeric) as a workaround.

I get that this is not part of the pdf standard and it's unfortunate that other viewers have implemented hacks to support malformed pdfs, which in turn leads such pdfs becoming popular in the wild.

---

Still, I'm not in control of the pdf generation and I can't tell clients that their pdf is invalid and they have to submit a new one given that they can see the contents of said pdf with other viewers.