0

我在 Ghostscript 9.06 中看到了一些奇怪的行为，我想知道这是否与我的 PS 结构或其他原因有关。

我们定义了一个嵌入字体，然后尝试设置一个表单并使用它，如下所示。在下面，我还有一些行可以在不使用表单的情况下直接将文本放在页面上。

globaldict 
begin
true setglobal 
/frm_test <<
/FormType 1 /BBox [-842 -842 596 596] /Matrix [1 0 0 1 0 0] /PaintProc { pop
/ArialMT 7.0 selectfont
0 0 moveto
(Test text form) show
}   %endPaintProc
>> /Form defineresource pop
/form_test {/frm_test /Form findresource true setglobal execform false setglobal} bind def
%/form_test {/frm_test /Form findresource execform} bind def
false setglobal
end

gsave
10 820 translate
form_test
grestore

/ArialMT 7.0 selectfont
10 800 moveto
(Test text normal) show
showpage

这里的问题是对 form_test 的调用会破坏两种情况下的字体定义——Ghostscript 找不到指定的字体。如果我从不调用 form_test 那么第二种情况有效。

如果我将 /form_test 行与下面注释掉的行交换，那么它可以正常工作。但是这条线在做什么？它似乎迫使表单在全局 VM 区域内运行，但我不确定为什么这很重要，以及为什么如果发生任何错误会传播到以下“selectfont”。

为什么 Acrobat Distiller 可以处理这个问题 - Postscript 是否正确？谢谢。

编辑：显然将周围的命令更改为保存/恢复而不是 gsave/grestore 可以防止问题影响第二个文本，但这并不能解释为什么表单中的字体未知。我也相信 gsave/grestore 应该足够了，因为除了图形状态之外，表单应该没有副作用。

4

1 回答 1

0

ArailMT 几乎肯定不是“字体”，它是 TrueType 字体，除非您之前嵌入了 42 型定义，否则总是很难从 PostScript 程序的片段中分辨出来。

你到底为什么要在全球 VM 中做所有事情？也使用 globaldict 吗？这些都是非常糟糕的做法，全局 VM 中的任何内容都不会受到保存和恢复，因此它会占用内存直到工作结束。

实际上在全局 VM 上下文中执行表单更糟糕，因为它会将表单过程中定义的任何资源存储在全局 VM 中。由于您调用将定义字体资源的“selectofnt”，除非它已经存在。因为您正在使用全局 VM 运行，所以它将在全局 VM 中而不是本地 VM 中定义字体，从而占用更多内存。

PostScript 是“正确的”，就像 C 程序可以在词法上正确，但不能按照您的期望进行。

如果您没有充分的理由使用全局 VM，那么不要，是最简单的答案。

于 2013-08-28T07:23:47.987 回答