[okular] [Bug 395660] okular cannot preserve annotations in some pdf files.

[Tobias Deiminger]

https://bugs.kde.org/show_bug.cgi?id=395660

--- Comment #5 from Tobias Deiminger <haxtibal at posteo.de> ---
(In reply to Tobias Deiminger from comment #4)
> - First object number > 0 doesn't indicate a damaged file, but it's valid
> (am unsure about this)
After investigating a bit more, now I think not having an object 0 is invalid.
This would mean '1_PDFsam_Untitled 2.pdf' is invalid, and poppler is NOT to
blame (maybe poppler could provide a workaround, though).

Standard section 7.5.4 is explicit that an old fashioned XRef table needs a
special object 0:
"The first entry in the table (object number 0) shall always be free and shall
have a generation number of 65,535; it is shall be the head of the linked list
of free objects."

Now '1_PDFsam_Untitled 2.pdf' has no XRef table but an XRef stream, and it
seems a bit ambigous if the above statement about object 0 applies for XRef
streams too. This needs to be clarified before we can actually blame either
poppler or pdfsam. Maybe ask at adobe forum, or poppler list?

The XRef stream in '1_PDFsam_Untitled 2.pdf' looks like this (needed to decode
/Filter /FlateDecode first)

$ dd if=1_PDFsam_Untitled\ 2.pdf ibs=1 skip=5841 count=64 | python -c 'import
zlib;import sys;sys.stdout.write(zlib.decompress(sys.stdin.read()))' | hexdump
-e '5/1 " %02X" "\n"'
 01 13 73 00 00 # Object 1. Type 1 (used, not compressed), object offset =
0x1373, generation 0
 01 00 0F 00 00 # Object 2. Type 1 (used, not compressed), object offset = 0xf,
generation 0
 02 00 01 00 00 # Object 3. Type 2 (compressed), stored in object nr.1, index
in object stream 0
 02 00 01 00 01 # Object 4. Type 2 (compressed), stored in object nr.1, index
in object stream 1
 02 00 01 00 02 # Object 5. Type 2 (compressed), stored in object nr.1, index
in object stream 2
 02 00 01 00 03 # Object 6. Type 2 (compressed), stored in object nr.1, index
in object stream 3
 02 00 01 00 04 # Object 7. Type 2 (compressed), stored in object nr.1, index
in object stream 4
 02 00 01 00 05 # Object 8. Type 2 (compressed), stored in object nr.1, index
in object stream 5
 02 00 01 00 06 # Object 9. Type 2 (compressed), stored in object nr.1, index
in object stream 6
 01 00 6F 00 00 # Object 10. Type 1 (used, not compressed), object offset =
0x6f, generation 0
 02 00 01 00 07 # Object 11. Type 2 (compressed), stored in object nr.1, index
in object stream 7
 02 00 01 00 08 # Object 12. Type 2 (compressed), stored in object nr.1, index
in object stream 8
 02 00 01 00 09 # Object 13. Type 2 (compressed), stored in object nr.1, index
in object stream 9
 01 01 0D 00 00 # Object 14. Type 1 (used, not compressed), object offset =
0x10d, generation 0
 01 02 3E 00 00 # Object 15. Type 1 (used, not compressed), object offset =
0x23e, generation 0
 01 15 ED 00 00 # Object 16. Type 1 (used, not compressed), object offset =
0x15ed, generation 0
 01 16 01 00 00 # Object 17. Type 1 (used, not compressed), object offset =
0x1601, generation 0

You see, no special object 0 here. It would look something like this
 00 00 00 FF FF # Object 0. Type 0 (member of linked list of free objects),
generation nr. 65535

-- 
You are receiving this mail because:
You are the assignee for the bug.