Created attachment 135069 [details] "corrupt" pdf file Hello, I have a program that takes an input PDF ads text at three coordinates and outputs it back to a new PDF file. I can successfully do this to a number of PDFs. I have however one very simple PDF file that once edited cannot be read by evince (pdfinfo, pdftocairo and friends as well), but can by every other PDF reader I've tried.
Created attachment 135070 [details] Original PDF
The problem is that the W field is 1 8 8, and we're only prepared for 4 bytes in the gen field. The attached patch fixes it but also makes each entry 4 bytes bigger, i guess it's the prize we have to pay unless we want to make the size of XRefEntry somehow depend on the W field values? Comments from anyone?
Created attachment 135172 [details] [review] the said patch
I think it is safe to assume that gen numbers will always fit in an int. The PDF spec says gen numbers must start at 0 and be incremented on each save so it should not be possible to get > 32-bit gen numbers without the PDF file becoming impracticably huge. I suggest accept 8-byte fields but store it in an int and print an error if is too big. I'm confident we will never see that error reported. But if you really want to use a 64-bit: - int gen; + Goffset gen; use long long. Goffset is for file offsets.
Created attachment 135666 [details] [review] New patch Adrian, what do you think, should i commit now?
Looks good.
Pushed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.