Error in PDF root object

Christopher picture Christopher · Jun 1, 2011 · Viewed 9.9k times · Source

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

Answer

Kurt Pfeifle picture Kurt Pfeifle · Jun 3, 2011

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:

  1. Garbage after %%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.
  2. Invalid character in name token: This is inside the name token /#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.