Ghostscript 不会使用在 DOCINFO 中检测到的 UTF16BE 文本字符串生成 PDF/A - 尽管 PDFACompatibilityPolicy 另有说明
Ghostscript won't generate PDF/A with UTF16BE text string detected in DOCINFO - in spite of PDFACompatibilityPolicy saying otherwise
我正在尝试使用此命令行将普通 PDF 文件转换为 PDF/A：
gs -dPDFA -dBATCH -dNOPAUSE -sProcessColorModel=DeviceCMYK -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=output.pdf input.pdf
但是，我收到消息
GPL Ghostscript 9.26: UTF16BE text string detected in DOCINFO cannot be represented in XMP for PDF/A1, reverting to normal PDF output
gs 恢复为普通 PDF。
显然，该消息源于 gs 的 this code fragment，但我们在那里读到该消息仅在 pdev->PDFACompatibilityPolicy == 0 时才会出现。我的理解是命令行中的参数-sPDFACompatibilityPolicy=1有防止这种情况的目的。
问： 为什么 gs 的行为就像所需的策略是 0 而不是 1？还有其他方法可以将策略设置为 1 吗？
另外，正好让我好奇：
Q: 有没有什么办法可以看出是什么奇怪的 DOCINFO 引起了原来的问题，或者在第一时间阻止它？使用 Acrobat Reader，我在文件中看不到任何内容 "suspicuous"。如果有帮助： input.pdf 是在 Window 上从 Word 生成的（我什至尝试使用 UseISO19005-1 设置，它应该首先生成 PDF/A，但问题仍然存在） .
您已输入 -sPDFACompatibilityPolicy=1。恐怕那是不正确的。 Ghostscript 有两种开关 -s 处理字符串值，-d 处理数字和名称值（PostScript 中的名称以 '/' 开头）。
您已将字符串值“1”分配给参数 PDFACompatbilityPolicy，该参数（内部）需要一个数值。由于需要从 PostScript 环境访问这些值这一事实，我们不能将类型混淆标记为错误。相反，我们将 actual 控件保留为默认值 0.
如果您改为设置 -dPDFACompatibilityPolicy=1，我希望您会看到预期的行为。
至于看数据，不看PDF文件我也说不出来。但是，如果此时停止在调试器中并查看 p->data，您将能够看到数据是什么。如果您查看 pairs + i 而不是 pairs + i + 1，您将能够看到与 DOCINFO pdfmark 中的值关联的键。
通过在 Acrobat 中查看文件，您将无法看到任何内容 'suspicious'，因为 Acrobat 会将 UTF16BE 转换为您的系统所需的任何内容，以便正确显示文本。甚至可能这是 ASCII，您仍然可以将其表示为 UTF16。
如果您在文本编辑器中打开该文件，您可能能够看到相关的字符串（注意 Ghostscript 中的 BOM 是八进制的，所以 0xFE 0xFF 是十六进制的), 前提是它不在压缩对象流中。
检查最新的 ghostscript (9.50) 的来源，似乎在这种情况下 PDFACompatibilityPolicy 值（参见第 1951 行附近的 devices/vector/gdevpdfm.c）设置包含错误的行为：
- 0 将恢复为正常的 PDF 输出（不是我真正想要的）
- 1 将丢弃 PDFINFO（甚至更糟）
- 2 会抛出错误（甚至更糟）
- 任何其他值在开关中都会被忽略并作为传递！
因此，就我而言，整个问题只需通过设置
就可以解决
-dPDFACompatibilityPolicy=3
Ghostscript 不会抱怨，不会中止 PDF/A 输出，不会丢弃 PDFINFO，而且最重要的是，veraPDF 检查器仍然会验证 PDF 是否完全正确。
我不是在评论这个解决方案有多丑，但它工作得很好。由于所有其他 switch 语句仅假设兼容性策略 0 如果传入大于 2 的任何内容，此 "shortcut" 似乎是一个意外但非常有用的错误。
exa的答案不太正确。 Ghostscript 将继续其输出，但生成的 pdf 将不符合 veraPDF 验证器。
此刻我正忙于让 ghostscript 工作，所以我得到了一个有效的 zugferd 发票 pdf。因此，PDF 必须是有效的 PDF/A-3（a、b 或 u）文件。
答案有问题
如果您只使用 -dPDFACompatibilityPolicy=3 verPDF 将不会验证 PDF。
相反，您应该使用正确的编码修复文件。
在我的例子中，pdf 看起来像这样：
如何解决：
使用以下内容创建一个新文件（例如“pdfmarks”）：
[ /Title (Foo Title)
/Author (Foo Bar)
/Subject (Foo Bar Subject)
/Keywords ()
/ModDate (D:20061204092842)
/CreationDate (D:20061204092842)
/Creator (Foo Bar)
/Producer (Foo Bar)
/DOCINFO pdfmark
(没有结束方括号']')
运行 像这样：
Windows:
"C:\Program Files\gs\gs9.53.3\bin\gswin64c.exe" -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=/path/to/output.pdf /path/to/input.pdf /path/to/pdfmarks
Linux:
gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=/path/to/output.pdf /path/to/input.pdf /path/to/pdfmarks
您可以添加您的东西或再次调用 gs。
我希望我能用这个来保护你们一些时间。
我正在尝试使用此命令行将普通 PDF 文件转换为 PDF/A：
gs -dPDFA -dBATCH -dNOPAUSE -sProcessColorModel=DeviceCMYK -sDEVICE=pdfwrite -sPDFACompatibilityPolicy=1 -sOutputFile=output.pdf input.pdf
但是，我收到消息
GPL Ghostscript 9.26: UTF16BE text string detected in DOCINFO cannot be represented in XMP for PDF/A1, reverting to normal PDF output
gs 恢复为普通 PDF。
显然，该消息源于 gs 的 this code fragment，但我们在那里读到该消息仅在 pdev->PDFACompatibilityPolicy == 0 时才会出现。我的理解是命令行中的参数-sPDFACompatibilityPolicy=1有防止这种情况的目的。
问： 为什么 gs 的行为就像所需的策略是 0 而不是 1？还有其他方法可以将策略设置为 1 吗？
另外，正好让我好奇：
Q: 有没有什么办法可以看出是什么奇怪的 DOCINFO 引起了原来的问题，或者在第一时间阻止它？使用 Acrobat Reader，我在文件中看不到任何内容 "suspicuous"。如果有帮助： input.pdf 是在 Window 上从 Word 生成的（我什至尝试使用 UseISO19005-1 设置，它应该首先生成 PDF/A，但问题仍然存在） .
您已输入 -sPDFACompatibilityPolicy=1。恐怕那是不正确的。 Ghostscript 有两种开关 -s 处理字符串值，-d 处理数字和名称值（PostScript 中的名称以 '/' 开头）。
您已将字符串值“1”分配给参数 PDFACompatbilityPolicy，该参数（内部）需要一个数值。由于需要从 PostScript 环境访问这些值这一事实，我们不能将类型混淆标记为错误。相反，我们将 actual 控件保留为默认值 0.
如果您改为设置 -dPDFACompatibilityPolicy=1，我希望您会看到预期的行为。
至于看数据，不看PDF文件我也说不出来。但是，如果此时停止在调试器中并查看 p->data，您将能够看到数据是什么。如果您查看 pairs + i 而不是 pairs + i + 1，您将能够看到与 DOCINFO pdfmark 中的值关联的键。
通过在 Acrobat 中查看文件，您将无法看到任何内容 'suspicious'，因为 Acrobat 会将 UTF16BE 转换为您的系统所需的任何内容，以便正确显示文本。甚至可能这是 ASCII，您仍然可以将其表示为 UTF16。
如果您在文本编辑器中打开该文件，您可能能够看到相关的字符串（注意 Ghostscript 中的 BOM 是八进制的，所以 0xFE 0xFF 是十六进制的), 前提是它不在压缩对象流中。
检查最新的 ghostscript (9.50) 的来源，似乎在这种情况下 PDFACompatibilityPolicy 值（参见第 1951 行附近的 devices/vector/gdevpdfm.c）设置包含错误的行为：
- 0 将恢复为正常的 PDF 输出（不是我真正想要的）
- 1 将丢弃 PDFINFO（甚至更糟）
- 2 会抛出错误（甚至更糟）
- 任何其他值在开关中都会被忽略并作为传递！
因此，就我而言，整个问题只需通过设置
就可以解决-dPDFACompatibilityPolicy=3
Ghostscript 不会抱怨，不会中止 PDF/A 输出，不会丢弃 PDFINFO，而且最重要的是，veraPDF 检查器仍然会验证 PDF 是否完全正确。
我不是在评论这个解决方案有多丑，但它工作得很好。由于所有其他 switch 语句仅假设兼容性策略 0 如果传入大于 2 的任何内容，此 "shortcut" 似乎是一个意外但非常有用的错误。
exa的答案不太正确。 Ghostscript 将继续其输出，但生成的 pdf 将不符合 veraPDF 验证器。
此刻我正忙于让 ghostscript 工作，所以我得到了一个有效的 zugferd 发票 pdf。因此，PDF 必须是有效的 PDF/A-3（a、b 或 u）文件。
答案有问题
如果您只使用 -dPDFACompatibilityPolicy=3 verPDF 将不会验证 PDF。
相反，您应该使用正确的编码修复文件。
在我的例子中，pdf 看起来像这样：
如何解决：
使用以下内容创建一个新文件（例如“pdfmarks”）：
[ /Title (Foo Title)
/Author (Foo Bar)
/Subject (Foo Bar Subject)
/Keywords ()
/ModDate (D:20061204092842)
/CreationDate (D:20061204092842)
/Creator (Foo Bar)
/Producer (Foo Bar)
/DOCINFO pdfmark
(没有结束方括号']')
运行 像这样：
Windows:
"C:\Program Files\gs\gs9.53.3\bin\gswin64c.exe" -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=/path/to/output.pdf /path/to/input.pdf /path/to/pdfmarks
Linux:
gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pdfwrite -sOutputFile=/path/to/output.pdf /path/to/input.pdf /path/to/pdfmarks
您可以添加您的东西或再次调用 gs。
我希望我能用这个来保护你们一些时间。