PDF根对象错误 [英] Error in PDF root object

问题描述

此PDF根对象将使Adobe Reader失败. Foxit，Nuance，Evince，SumatraPDF等其他PDF阅读器将打开PDF文件而不会出现问题.问题是/Dests要求一个间接对象(PDF参考).删除/目的地<< >>将使Adobe Reader打开文件，但打印失败.其他所有读者都可以在没有/Dest的情况下正常工作.在下面的根对象示例中，您有任何想法如何纠正语法?

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...

所以我注意到的第一件事是* 所有其他阅读器确实可以打开文件(我只测试了一些).但是这些确实会吐出很多警告和错误消息...(尝试使用Ghostscript:gs virkerikke.pdf，或者尝试使用evince ...).PDF中至少还有一个损坏的xref表(或者至少是这是投诉之一).

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).

[....]
Error: Invalid XRef entry
Error: Invalid XRef entry
Error: Invalid XRef entry
Error (157): Unterminated string
Error (159): End of file inside dictionary

gv抱怨:

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抱怨:

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抱怨:

gs complains:

**** Warning: File has a corrupted %%EOF marker, or garbage after %%EOF.

mupdf抱怨:

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抱怨:

qpdf --qdf complains:

virkerikke.pdf (object 17 0, file position 2234): null character not allowed in name token

---

好的，现在在文本编辑器中打开这个糟糕的文件，尝试修复它.我发现此文件(大小为32746字节)存在一些严重的语法问题:

---

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. %%EOF之后的垃圾::在其%%EOF标记后的标题为"Wkhtmltopdf-Teknisk regelverk" .它的大小是11878字节.删除此部分，您将得到一个更好的" PDF，仅剩20868字节大小……尽管在保存编辑后的文件之后，Acrobat/Adob​​e Reader仍然没有打开它.
2. 名称令牌中的无效字符:这位于名称令牌/#8d#c2#ca#ebs#e4#60#00#9e#97l#b9#80#1b#cb#86sQR#83中.在此文件中显示为2x.在我的第一句话中，我已经告诉您该密钥对我而言似乎并不可信，因为它仅包含很少的ASCII字符，但是包含许多二进制字节(使用它们的十六进制表示.(我忽略的是，它甚至包含一个#00是nul字符的PDF表示...在PDF中的名称标记非法使用.)用另一个(幻像)替换该名称标记，该长度完全相同(两次出现) .我确实选择了/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.保存编辑的文件.

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.

现在，即使Acrobat/Adob​​e Reader也可以打开此修复文件，而不会提出投诉.此外，其他读者" 现在可以使用此文件更好地工作，发出更少的警告，并且现在能够识别他们无法识别的某些元数据(例如创建日期和生产者== wkhtmltopdf)进入原始文件.

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.

这篇关于PDF根对象错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！