uriHeart / pdfium

Automatically exported from code.google.com/p/pdfium
0 stars 0 forks source link

Object numbers shifted down after xref table entry 0000000000 65535 f #36

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Update an object (having object number N) 65534 times, then free it
2. Load the document in PDFium
3. All objects after N are shifted down one position

(Step 1 can be sped up by using editing the file directly or using a
PDF creator that uses generation number 65535 for free objects to
prevent objects from being reused or for whatever reason.)

What is the expected output? What do you see instead?

Expected: The attached document shows the test "ABC" on the first (and only) 
page.
Observed: Blank page.

What version of the product are you using? On what operating system?

git tag 6c673585ed6bcb9e330ea5ab716f496c5d5f37b4 of PDFium
Linux x86_64

Please provide any additional information below.

"0000000000 65535 f" is a perfectly valid xref table entry. There are some
broken PDF files which do have an extra xref entry of that type, requiring
shifting the xref table entries down. However, PDFium does that in too
many cases and breaks documents in the process. The broken documents I've
seen have an xref table starting at object number 1 with "0000000000 65535 f"
(which is what the xref table entry for object 0 should look like). You might
want to peek at the object pointed to by the next non-free object and compare
the object numbers (the index into the xref table and the object number found
in the actual object) to see if they differ by one.

Original issue reported on code.google.com by eb.mat...@gmail.com on 5 Aug 2014 at 2:00

Attachments:

GoogleCodeExporter commented 9 years ago
s/using editing/editing/

Original comment by eb.mat...@gmail.com on 5 Aug 2014 at 2:03

GoogleCodeExporter commented 9 years ago
I blame these lines of fpdf_parser_parser.cpp:

                            if (offset == 0 && version == 65535 && start_objnum != 0) {
                                start_objnum--;
                                objnum = 0;
                            }

Original comment by eb.mat...@gmail.com on 5 Aug 2014 at 2:04