Re: [Printing-architecture] PDFio: Replaced QPDF by PDFio in libcupsfilters as GSoC project?

Alex,

> On Dec 11, 2023, at 11:12 AM, Alex Korobkin <[email protected]> wrote:
> 
> Hello printing folks, 
> 
> If you don't mind, may I chime in from the user's perspective? As you know, there are lots of bad PDFs out there, and even if they represent only 0.1% of the total number of all PDFs that people print, one million print jobs turns into 1000 tickets about unprintable files. QPDF is extremely accommodating about it: no matter how bad a PDF is, it will try to recover and proceed. Over the last few years I filed numerous requests about handling some despicable PDFs, and all of them were accepted.
> 
> How is PDFio with regards to handling bad PDFs? Is there any testing tool with PDFio compiled in that I can run against my corpus of bad PDFs to see how it would treat them?

The "testpdfio" program specifically does this.  With no arguments it runs PDFio's unit tests, but if you pass in a filename you'll get a list of pages/objects:

    ./testpdfio FILENAME.pdf

    ./testpdfio --verbose FILENAME.pdf

    ./testpdfio FILENAME.pdf OBJECT-NUMBER >OBJ.dat

I also have a large corpus I test with (which includes the PDF Association's Stressful PDF Corpus) and the only two open issues I have are:

1. Currently PDFio will not reconstruct a missing/broken xref table, and
2. I have one file that uses two different encryption keys for different parts of the file (this looks to be an encrypted file that was later edited with Acrobat, with the changes written with a separate key...)

I have my concerns about enabling #1 by default, as it could open up security issues (denial-of-service for sure, possibly data corruption). 
For #2 I'll come up with a fix but this is the first time I've ever seen a PDF file with multiple encryption keys (the spec doesn't disallow it but also doesn't talk about needing to support it...) so I'm not sure how common they are...

________________________
Michael Sweet