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

Thank you, that's exactly what I needed.
I ran it against my collection of bad PDFs, and 10% of them failed with "
Malformed xref table entry '0000000000 65536 f'."
I suppose that's the #1 point from your reply, so perhaps it's not too
bad of an idea to reconstruct the xref table when possible?

It also reported "Too many object streams." for one file with 7000 pages,
and "Unexpected 'startxref' token seen." on this file created by Till in
2013 to test various page sizes in a single PDF.


On Mon, Dec 11, 2023 at 11:24 AM Michael Sweet <[email protected]> wrote:

> 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
>
>

-- 
-Alex