Error reported loading some PDFs

[Phil28073338r0c0]

I am having problems with some PDFs created using Perl package PDF::TableX with PDF::Builder, on Windows 10. When created with no compression, Adobe Acrobat Reader (64 bit) displays it fine, but with Flate compressed streams, the PDF loads but is overlaid with a dialog "An error exists on this page. Acrobat may not display the page correctly. Please contact..." Press "OK" and everything seems to be fine, and Acrobat does not request permission to save the (changed?) file upon exit (as it normally does if it fixed something upon load). I have been trying for literally days to find what's wrong with the PDF (compressed version) and have found nothing. Everything seems to be clean. I even ran PDFtk against it to created an uncompressed version, which displays without error, and the streams appear to be identical in size and content with the originally uncompressed version.

01compressed.pdf  =  with compression, shows error upon load

01uncomp.pdf        =  created without compression, no errors reported

01decomp.pdf        =  uncompressed by PDFtk from 01compressed.pdf, no errors reported

Maybe some of you have better debuggers and can find what the error is. I have tried PDFXplorer and pdf-online.com, and neither report any problems (just 122 informational messages about a path being defined but not used). The compressed PDF displays cleanly in Firefox, Chrome, and Edge, as well as with XpdfReader, and uncompresses in PDFtk without reported problems. That suggests that either it's a very subtle problem in the PDF, or there's a bug in Acrobat. Adobe products, particularly Acrobat (the free downloaded version, BTW) are the Gold Standard for PDF Readers, so I'd really like to see it display properly in Acrobat. Thanks!

P.S. This is a (Perl) test program from PDF::TableX, that creates a chessboard with each square labeled with the color. I didn't write it, so please don't complain about things like the Times-Roman core font being defined 64 times (once for each piece of text) instead of just once. I am the author of PDF::Builder, the library it uses to actually generate a PDF. There is another test program (03) that also produces this particular error, but I want to see if any fix for this one fixes that one, too. Then I've got several PDFs generated from TIFF files that won't display at all, but I'll deal with those in a later ticket.

[Phil28073338r0c0]

Has anyone been able to reproduce this problem? It's only the compressed PDF, and it's only with Adobe Acrobat Reader (free download version). I'm hoping that someone has access to a good PDF debugger that will indicate what Reader is choking on.

[Phil28073338r0c0]

Has anyone had a chance to try this? It is only the (free version) Adobe Acrobat Reader that refuses to load this PDF without an error message. XpdfReader, GIMP, and the PDF viewers that come with Firefox, Chrome, and Edge are all happy to load it without complaint. It's possible that there is a very subtle bug in Acrobat, but nearly as likely a subtle error in the PDF that only Acrobat is catching (it is the Gold Standard, anyway!).If only it would tell me what it didn't like about the PDF...

[Phil28073338r0c0]

Are there any free downloadable or online diagnostic tools for PDFs? Doesn't have to be from Adobe, although that would be preferable. Or, are there diagnostics within Reader? There are plenty of tools to "repair" a PDF, but what I need is something to tell me what's wrong with a PDF, so I can fix the software that produced the PDF in the first place. It's useless to have a repair tool simply hand me a "repaired" PDF, because the fix is usually a complete rewrite of the PDF, and I can't tell what it fixed! Plus, if I can diagnose problems myself, I won't have to bother the Community with questions.

[Phil28073338r0c0 · Accepted solution]

Some more or less good news... fellow Perler and PDF maven Vadim Repin looked at the PDF and determined that the problem was the presence of save (q) and restore (Q) calls in a text stream. Apparently the standard sort of forbids these, and my removing these calls (making them no-ops, with a warning message) in PDF::Builder seems to take care of the problem. Rather odd that it happened only with compressed streams, and possibly only sometimes with compressed streams! In any case, it apparently works now, so I'll close this ticket.