为什么使用pdfmark/BP、/EP、/SP时，ghostscript的速度要快得多？

我们有一些我正在努力理解的遗留代码——原作者已经不在了

显然，Ghostscript PS到PDF的转换对于某些文件来说非常慢，但是将对象定义放在下面会大大加快转换速度（对于一个20000页的文件，我们说的是8个多小时到8.5分钟，而Adobe Distiller在原始文件上使用默认选项需要20分钟）

原始文件摘录（使用PReS创建）：

/@GP
{
  save exch mark exch
  execform
  cleartomark restore
} bd
...
gsave 0.62 0.62 scale @TestGraphic @GP grestore

[/_objdef {new_graphic} /BBox [0 0 595 842] /BP pdfmark
@TestGraphic @GP
[/EP pdfmark
...
gsave 0.62 0.62 scale 
[ {new_graphic} /SP pdfmark
grestore

其中@TestGraphic是一个EPS图像。这似乎并不重要，因为其他程序使用具有类似问题的不同非EPS图像

修改的文件：

/@GP
{
  save exch mark exch
  execform
  cleartomark restore
} bd
...
gsave 0.62 0.62 scale @TestGraphic @GP grestore

[/_objdef {new_graphic} /BBox [0 0 595 842] /BP pdfmark
@TestGraphic @GP
[/EP pdfmark
...
gsave 0.62 0.62 scale 
[ {new_graphic} /SP pdfmark
grestore

在不同的

gs

版本上，我们在Unix和Windows上都看到了类似的行为。时间安排采用了相当标准的选项：

"c:\Program Files (x86)\gs\gs9.21\bin\gswin32c" \
   -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -o test.pdf test.ps

我不太感兴趣的是诊断它为什么慢（从文件中删除敏感数据需要很长时间，但如果真的需要，我可以尝试），而是目标定义和pdfmark命令提供了什么好处

原始脚本引用并设计用于在某些打印机RIP和蒸馏器上启用execform缓存（每个打印机RIP和蒸馏器都难以处理大型全彩图像），但是Ghostscript不支持execform缓存，因此采用了此替代pdfmark技术，但没有说明原因

编辑：添加表单定义要点，删除数据：

/@GP
{
  save exch mark exch
  execform
  cleartomark restore
} bd
...
gsave 0.62 0.62 scale @TestGraphic @GP grestore

[/_objdef {new_graphic} /BBox [0 0 595 842] /BP pdfmark
@TestGraphic @GP
[/EP pdfmark
...
gsave 0.62 0.62 scale 
[ {new_graphic} /SP pdfmark
grestore

---

您很可能正在使用较旧版本的Ghostscript。您的原始片段使用PostScript表单，这是不寻常的，pdfwrite设备的旧版本没有将表单保留为表单，而是在每次使用表单定义时“展开”表单定义

不出所料，这将导致更大的输出文件，特别是如果表单是内容的主要部分并且在每个页面上都使用的话

pdfmark代码定义一个PDF对象，然后每次都引用该对象。只有一个对象，因此文件要小得多，因此您花在组装它和复制相同数据上的时间要少得多

当然，新版本的pdfwrite设备将保留表单，因此直接创建和引用PDF对象的好处很可能早已消失

它与表单缓存无关（不是“execform缓存”），而是与输入PostScript中的表单是否作为表单保留在输出PDF中有关

---

顺便说一句，理解性能差的原因很重要，但您不可能理解另一种方法为什么更快。

谢谢Ken，我使用了包括9.21（如上所示的命令）在内的各种版本进行了测试。虽然pdfmark确实带来了好处，但这可能是由于构建表单的一种不常见的方式。展开所有重新定义的命令需要一段时间，以了解它真正在做什么。总共有30个表单，一些是缩略图大小，其他的占页面的75%。有些页面只有一个，而另一些页面有多个。明天我会深入挖掘。我需要看一个例子才能给出完整的答复。当前版本应该能够尊重表单，但老实说，pdfmark方法几乎肯定是最有效的，因为它不依赖于设备“发现”表单，而是显式命名并使用命名表单。没有启发式，没有检查它是否与现有的表单相同等etcI添加了一个要点，显示了表单是如何定义的，我知道这是一个长期的问题，但可能会有什么东西向你跳出来。现在我们将继续使用PDF标记，如果可能的话，我将在下周进一步研究。如果你想进一步了解的话，我还可以在GS bugzilla上提出一个bug。我现在正在度假，要到下周一才能回到我的办公桌。快速看一眼，表单的使用看起来并不完全合法，因为表单必须是原子的，它们不能依赖于解释器状态，也不能改变解释器状态。表单用于表单，而不是隔离程序代码块。您应该将EPS转换为表单定义，而不是随机读取EPS。老实说，在我看来，这可能就是问题所在，我们对此无能为力。看看它，这似乎只是一种（低效的）将每股收益转化为形式的方法。在没有看到表单后来是如何使用的情况下，我看不出有什么理由不能像使用Ghostscript时所预期的那样工作，但是所呈现的骨架太小了，无法确定。30种不同形式的声音，对我来说是次优的，但我对内容真的没有任何线索。