"hybrid PDF file"使用的标准是什么?
What the standard used by a "hybrid PDF file"?
我需要创建 Open and easily-readable "PDF with source-content" (also named PDF Hybrid) by software tool like Prince or PDFreactor... This DocumentFoundation's FAQ explain what it is a PDF Hybrid,但不说明使用的是什么标准:
PDF/A-3
个 ISO 19005-3?
- 其他(最简单的?)ISO 19005 功能?
- ISO 32000? (something as embedded files?)
检测已知的混合 PDF 文件的标准将是一个很好的替代方法...但是有人说它是 impossible to detect the standard 在 PDF Hybrid 中使用的文件。
首先,这个Hybrid PDF出现没有在独立的标准中指定,即没有相应的ISO/ETSI/ANSI/...标准。
话虽如此,这显然是 LibreOffice PDF 导出的一个突出特点:
(来自LibreOffice Writer FAQ on hybrid PDFs)
检查这样的文件(例如 this one)可以看到 PDF 预告片中还有其他条目:
...
trailer
<</Size 128/Root 126 0 R
/Info 127 0 R
/ID [ <518EBB4C2FE2F6B638478335A7ED9CA4>
<518EBB4C2FE2F6B638478335A7ED9CA4> ]
/DocChecksum /7B00A6EE0349EB2EA1DFB5ECC5899A7C
/AdditionalStreams [/application#2Fvnd#2Eoasis#2Eopendocument#2Etext 66 0 R
]
>>
startxref
291605
%%EOF
并且对象 66 中引用的 附加流 确实包含源 OpenOffice 文档。
显然,支持这些 混合 PDF 文件的应用程序会检查 AdditionalStreams 尾部条目的值,以及它们是否知道要处理给定的文档类型(/application#2Fvnd#2Eoasis#2Eopendocument#2Etext
这里对应 application/vnd.oasis.opendocument.text),它们提供了一种提取嵌入文档并打开它进行编辑的方法。
注意:除非我忽略了一些 ISO 规范,否则这些额外的条目严格来说是 禁止的 PDF 规范 ISO 32000:在trailer 可能只有带有在 ISO 规范中为 trailer 定义的键或 any second-class names 的条目。 AdditionalStreams 和 DocChecksum 都不是 ISO 指定的或第二个 class。因此,严格来说,那些 混合 PDF 是无效的 PDF。
我需要创建 Open and easily-readable "PDF with source-content" (also named PDF Hybrid) by software tool like Prince or PDFreactor... This DocumentFoundation's FAQ explain what it is a PDF Hybrid,但不说明使用的是什么标准:
PDF/A-3
个 ISO 19005-3?- 其他(最简单的?)ISO 19005 功能?
- ISO 32000? (something as embedded files?)
检测已知的混合 PDF 文件的标准将是一个很好的替代方法...但是有人说它是 impossible to detect the standard 在 PDF Hybrid 中使用的文件。
首先,这个Hybrid PDF出现没有在独立的标准中指定,即没有相应的ISO/ETSI/ANSI/...标准。
话虽如此,这显然是 LibreOffice PDF 导出的一个突出特点:
(来自LibreOffice Writer FAQ on hybrid PDFs)
检查这样的文件(例如 this one)可以看到 PDF 预告片中还有其他条目:
...
trailer
<</Size 128/Root 126 0 R
/Info 127 0 R
/ID [ <518EBB4C2FE2F6B638478335A7ED9CA4>
<518EBB4C2FE2F6B638478335A7ED9CA4> ]
/DocChecksum /7B00A6EE0349EB2EA1DFB5ECC5899A7C
/AdditionalStreams [/application#2Fvnd#2Eoasis#2Eopendocument#2Etext 66 0 R
]
>>
startxref
291605
%%EOF
并且对象 66 中引用的 附加流 确实包含源 OpenOffice 文档。
显然,支持这些 混合 PDF 文件的应用程序会检查 AdditionalStreams 尾部条目的值,以及它们是否知道要处理给定的文档类型(/application#2Fvnd#2Eoasis#2Eopendocument#2Etext
这里对应 application/vnd.oasis.opendocument.text),它们提供了一种提取嵌入文档并打开它进行编辑的方法。
注意:除非我忽略了一些 ISO 规范,否则这些额外的条目严格来说是 禁止的 PDF 规范 ISO 32000:在trailer 可能只有带有在 ISO 规范中为 trailer 定义的键或 any second-class names 的条目。 AdditionalStreams 和 DocChecksum 都不是 ISO 指定的或第二个 class。因此,严格来说,那些 混合 PDF 是无效的 PDF。