This PDF root object will get Adobe Reader to fail. Other PDF readers like Foxit, Nuance, Evince, SumatraPDF will open the PDF file without problems. The problem is /Dests which reguires an indirect object (PDF reference). Deleting the /Dests << >> will get Adobe Reader to open the file, but fail on printing. All the other readers work OK without the /Dests. Any ideas how to correct the syntax in the following root object example?
17 0 obj
<<
/Type /Catalog
/Pages 2 0 R
/Outlines 15 0 R
/PageMode /UseOutlines
/Dests <<
/__WKANCHOR_2 8 0 R
/#8d#c2#ca#ebs#e4#60#00#9e#97l#b9#80#1b#cb#86sQR#83 9 0 R
>>
>>
endobj
OK, found a few spare minutes...
So the first thing I noticed is that *all other readers indeed may open the file (I only tested a few). But these do spit out lots and lots of warnings and error messages... (Try Ghostscript: gs virkerikke.pdf
, or try evince...) There is at least a damaged xref
table in the PDF as well (or at least this is one of the complaints).
xpdf
complains:[....]
Error: Invalid XRef entry
Error: Invalid XRef entry
Error: Invalid XRef entry
Error (157): Unterminated string
Error (159): End of file inside dictionary
gv
complains:Warning: translation table syntax error: Unknown keysym name: apLineDel
Warning: ... found while parsing '<Key>apLineDel: GV_Page(page+5) '
Warning: String to TranslationTable conversion encountered errors
evince
complains:[....]
Error: Invalid XRef entry
Error: Invalid XRef entry
Error: Invalid XRef entry
Error (157): Unterminated string
Error (159): End of file inside dictionary
Error (157): Unterminated string
Error (159): End of file inside dictionary
Error (157): Unterminated string
Error (159): End of file inside dictionary
[....]
Error (1918): Unterminated string
Error (1920): End of file inside dictionary
gs
complains:**** Warning: File has a corrupted %%EOF marker, or garbage after %%EOF.
mupdf
complains:+ pdf/pdf_xref.c:60: pdf_read_start_xref(): cannot find startxref
| pdf/pdf_xref.c:477: pdf_load_xref(): cannot read startxref
\ pdf/pdf_xref.c:532: pdf_open_xref_with_stream(): trying to repair
warning: ignoring invalid character in hex string: '!'
warning: ignoring invalid character in hex string: 'O'
warning: ignoring invalid character in hex string: 'T'
warning: ignoring invalid character in hex string: 'Y'
[....]
qpdf --qdf
complains:virkerikke.pdf (object 17 0, file position 2234): null character not allowed in name token
OK, now opening this crappy file in a text editor, trying to repair it. What I find is this that this file (32746 Bytes in size) has some serious syntax problems:
%%EOF
: There is a complete and syntax-correct HTML-File glued to the PDF after its %%EOF
marker with the title "Wkhtmltopdf - Teknisk regelverk". Its size is 11878 Bytes. Delete this part, and you'll have a 'better' PDF with a size of only 20868 Bytes left... though Acrobat/Adobe Reader still doesn't open it after you saved the edited file./#8d#c2#ca#ebs#e4#60#00#9e#97l#b9#80#1b#cb#86sQR#83
. It appears 2x in this file. Already in my first comments I told you that this key didn't look trustworthy to me, because it contains only very few ASCII characters, but lots of binary Bytes (using their hexadecimal representation. (What I had overlooked was that it even contained a #00
which is the PDF representation for a nul
character... the use of which is illegal for name tokens in PDF.) Replace that name token with another (phantasy) one of exactly the same length (on both occurrences). I did choose /aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
. Save the edited file.Now even Acrobat/Adobe Readers will open this repaired file without complaining. Also, the 'other readers' will work now better with this file, spitting out less warnings and now being able to identify some metadata (such as creation date and producer == wkhtmltopdf) which they were unable to get to for the original file.