(I posted this in Acrobat Discussions 3 months ago, with no response, so I'll try here instead.)
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 free version) 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 ages 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 GIMP, 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. I'm hoping that someone has access to a good PDF debugger that will indicate what Reader is choking on. 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.
How are you using the Acrobat SDK in this?
It doesn't use SDK at all, but a previous Acrobat question was moved to here by the moderators, and got answers. My latest question was on the Acrobat discussion, but got 0 replies, so I thought I'd try here.
Anyway, this is the free download of Acrobat Reader, and it's the only reader that complains about the PDF. I am hoping that someone has access to a decent debugger that could tell me what's wrong in the PDF. Then, I should be able to update the PDF creation software to avoid that issue.
Moderators, please feel free to move this to another category. I already have a ticket open in Adobe Discussions, which has gotten no response.
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.
Copy link to clipboard
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.