尝试在 CorelDRAW 中打开手动创建的 PDF 但失败

Question

更新并解决：我原本以为我的问题是一个更普遍的问题，但@KJ检查我的PDF文件后，实际上是我自己的文件中的错误。所以评论中的解决方案是针对我个人情况的。

给我和将来有类似情况的其他人的建议：仔细检查结构。 指针值必须100%正确；某些错误可能会给某些 pdf 阅读器带来问题。

原问题：

我正在尝试手动创建 PDF 文件作为我的项目的导出功能。几乎可以用了。这些文件可以使用 Adobe Acrobat 和 Illustrator 打开，并且完全可编辑。但这不适用于 CorelDRAW。

我的假设：

用Adobe Acrobat打开它时，即使没有更改，它总是要求我保存。保存后，文件可以在CorelDRAW中成功打开。所以我认为 Arcobat 做了一些事情来修复我的文件。我想知道它做了什么，是否可以创建一个完全符合Arobat标准的PDF，从而可以直接在CDR中打开。

我对此没有足够的背景知识。非常感谢您的任何帮助、意见和建议。

相关文件（我将字体文件嵌入到PDF文件中，所以我不想在这里复制代码；它会很长。）：

这是手动创建的PDF

这是在 Acrobat 中保存后的 PDF

或者，这里有一个类似的案例：

手动创建的原始pdf，无法通过CDR读取：

%PDF-1.4
<hex chars removed>
1 0 obj
<< /Pages 2 0 R /Type /Catalog >>
endobj
2 0 obj
<< /Count 1 /Kids [ 3 0 R ] /Type /Pages >>
endobj
3 0 obj
<< /Contents 4 0 R /MediaBox [ 0 0 500 800 ] /Parent 2 0 R /Resources 5 0 R /Type /Page >>
endobj
4 0 obj
<< /Length 57 >>
stream
BT /F1 24 Tf 175 720 Td <FEFF004821260065006C006C006F> Tj ET
endstream
endobj
5 0 obj
<< /Font << /F1 6 0 R >> >>
endobj
6 0 obj
<< /BaseFont /Courier /Subtype /Type1 /Type /Font >>
endobj
xref
0 7
0000000000 65535 f 
0000000015 00000 n 
0000000064 00000 n 
0000000123 00000 n 
0000000229 00000 n 
0000000335 00000 n 
0000000378 00000 n 
trailer << /Root 1 0 R /Size 7 /ID [<89311a609a751f1666063e6962e79bd5><89311a609a751f1666063e6962e79bd5>] >>
startxref
448
%%EOF

在 Acrobat 中保存后：

%PDF-1.6
%忏嫌
7 0 obj
<</Linearized 1/L 4686/O 9/E 1039/N 1/T 4397/H [ 443 130]>>
endobj
                       
12 0 obj
<</DecodeParms<</Columns 4/Predictor 12>>/Filter/FlateDecode/ID[<89311A609A751F1666063E6962E79BD5><1AF678699D64704CBB4D6708F363F3FE>]/Index[7 9]/Info 6 0 R/Length 47/Prev 4398/Root 8 0 R/Size 16/Type/XRef/W[1 2 1]>>stream
h辀bd``b`?6 ?H0.?012L?02齡茗 ? \N?
endstream
endobj
startxref
0
%%EOF
      
15 0 obj
<</Filter/FlateDecode/I 66/Length 51/S 38>>stream
h辀```f`` 層P#?p4 ?C1C泂LL`
T?€  狵?
endstream
endobj
8 0 obj
<</Metadata 1 0 R/Pages 5 0 R/Type/Catalog>>
endobj
9 0 obj
<</Contents 11 0 R/CropBox[0 0 500 800]/MediaBox[0 0 500 800]/Parent 5 0 R/Resources 13 0 R/Rotate 0/Type/Page>>
endobj
10 0 obj
<</Filter/FlateDecode/First 11/Length 72/N 2/Type/ObjStm>>stream
h?4V0P04Q02V氨褀讼+Q?!?;  驖婼ARE櫓E%?!@?L偟谫 :Uk
endstream
endobj
11 0 obj
<</Length 62>>stream
BT /F1 24 Tf 175 720 Td <FEFF004821260065006C006C006F> Tj ET

endstream
endobj
1 0 obj
<</Length 2988/Subtype/XML/Type/Metadata>>stream
<?xpacket begin="锘? id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 5.6-c017 91.164464, 2020/06/15-10:20:05        ">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:xmp="http://ns.adobe.com/xap/1.0/"
            xmlns:dc="http://purl.org/dc/elements/1.1/"
            xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/">
         <xmp:ModifyDate>2024-02-16T11:43:39+01:00</xmp:ModifyDate>
         <xmp:CreateDate>2024-02-16T11:43:39+01:00</xmp:CreateDate>
         <xmp:MetadataDate>2024-02-16T11:43:39+01:00</xmp:MetadataDate>
         <dc:format>application/pdf</dc:format>
         <xmpMM:DocumentID>uuid:51548485-b977-470f-8fa3-e46b5a112535</xmpMM:DocumentID>
         <xmpMM:InstanceID>uuid:8543361a-d2ca-46bb-8d6c-d303ebd0decf</xmpMM:InstanceID>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                                                                                                    
                           
<?xpacket end="w"?>
endstream
endobj
2 0 obj
<</Filter/FlateDecode/First 4/Length 48/N 1/Type/ObjStm>>stream
h?U0P氨褀??Q0憎蜭)幎?抨嘥り $Η圪 謜€
endstream
endobj
3 0 obj
<</Filter/FlateDecode/First 4/Length 62/N 1/Type/ObjStm>>stream
h?S0P氨褀.JM,商蟬I,I誴?202102434416对60T70P自魍O莲牢 ? &@?
endstream
endobj
4 0 obj
<</DecodeParms<</Columns 3/Predictor 12>>/Filter/FlateDecode/ID[<89311A609A751F1666063E6962E79BD5><1AF678699D64704CBB4D6708F363F3FE>]/Info 6 0 R/Length 37/Root 8 0 R/Size 7/Type/XRef/W[1 2 0]>>stream
h辀b```bd醙b帙赡佬媚?媺颀 ? ? *]
endstream
endobj
startxref
116
%%EOF

我认为关键是要了解Acrobat所做的哪部分更改是让CDR识别文件的关键。

Answer 1

Adobe Acrobat 通常会接受不正确的 PDF 程序，然后在关闭时提供完全重新编辑整个 PDF 程序结构。

新代码与原始代码几乎没有相似之处，因为它通常是“Web 增强型”（/线性化）。

触发完全重写的可能是语法中的小错误或多个错误的堆栈代码指令或嵌入变量。

大多数 PDF 编辑阅读器中的迭代过程是查看头部和尾部数据，然后使用这些十进制地址从文件指针运行应用程序线程。

因此，预告片数据必须正确，否则编辑器会进入错误函数，这些函数可能会或可能不会与这些指令和数据一起工作。

这种简化情况下的尾部结构必须位置完美并包含所有函数偏移地址。

对于上面的例子，我们应该有这样的东西。

%PDF-1.4
%£¬£¬
1 0 obj
<< /Pages 2 0 R /Type /Catalog >>
endobj
2 0 obj
<< /Count 1 /Kids [ 3 0 R ] /Type /Pages >>
endobj
3 0 obj
<< /Contents 4 0 R /MediaBox [ 0 0 500 800 ] /Parent 2 0 R /Resources 5 0 R /Type /Page >>
endobj
4 0 obj
<< /Length 60 >>
stream
BT /F1 24 Tf 175 720 Td <feff004821260065006c006c006f> Tj ET
endstream
endobj
5 0 obj
<< /Font << /F1 6 0 R >> >>
endobj
6 0 obj
<< /BaseFont /Courier /Subtype /Type1 /Type /Font >>
endobj
xref
0 7
0000000000 65536 f 
0000000015 00000 n 
0000000064 00000 n 
0000000123 00000 n 
0000000229 00000 n 
0000000339 00000 n 
0000000382 00000 n 
trailer
<< /Root 1 0 R /Size 7 /ID [ <89311A609A751F1666063E6962E79BD5><89311A609A751F1666063E6962E79BD5> ] >>
startxref
450
%%EOF

那么我的主要区别是什么？

1. 一个常见问题是以 UTF-8 保存文件会破坏 ANSI 结构。例如，我显示的二进制标记是 4 个字节

   £¬£¬

   ，但任何 UTF 都会将其更改为 8 个字节，或者当应该有 4 个简单的 ANSI 字节时，我们会看到 2 个复合字符。结果是从该点开始的所有地址都可能出错。因此，如果有先前的换行，则典型的第二个条目应为 15 或 16。在这种情况下，您正确使用 15。

2. 预告片是关键索引，如果用 Linux 风格 ANSI 编写，则每行末尾需要一个空格，否则在 Windows 中则不需要空格。所以 EOL 要么是 200A，要么是 0D0A（Mac 编码 =200D）

3. 指针值必须 100% 正确，否则将运行错误的部分代码。这就是我们不同的地方，你的长度是 57，我的长度是 60，因此从那时起，所有指针都是可疑的。