0

我有以下 GhostScript 命令，我调用它的目的是将输入 pdf 转换为一堆输出 PNG 图像（每页一个图像）：

"C:\Program Files\gs\gs9.07\bin\gswin64c.exe" \
   -dNOPAUSE \
   -q \
   -r150 \
   -sDEVICE=png16m \
   -dBATCH \
   -c "30000000 setvmthreshold" \
   -dNumRenderingThreads=8 \
   -sOutputFile="C:\output-%d.png" \
    "C:\input.pdf"

当我在 Windows 命令提示符中运行此命令时，它突然从我的默认打印机打印出一堆带有一堆编码字符的文件。它不会生成任何类型的 PNG 图像。

更新 省略-q给出：

GPL Ghostscript 9.07 (2013-02-14)
Copyright (C) 2012 Artifex Software, Inc.  All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 4.
Page 1
Page 2
Page 3
Page 4

更新 2： 感谢 KenS，我一次删除了一个部分，直到确认是以下参数破坏了它：

-c "30000000 setvmthreshold"

我在另一个论坛上得到了这个，试图提高 GS 的速度。我是用错了还是应该把它排除在外？PDF 将非常大并且有 100 页，所以我需要尽可能地优化。有什么建议么？

谁能指出我正确的方向？谢谢

4

3 回答 3

3

我相信重写命令行以更改参数的顺序并添加-f以表示输入文件应该可以使其工作：

"C:\Program Files\gs\gs9.07\bin\gswin64c.exe" -dNOPAUSE -q -r150 -sDEVICE=png16m -dBATCH  -dNumRenderingThreads=8 -sOutputFile=C:\output-%d.png -c "30000000 setvmthreshold" -f C:\input.pdf

如何使用 Ghostscript 中的以下内容应该很明显：

-c string ...将参数解释为 PostScript 代码，直到下一个以 " -" 后跟非数字或以 " @" 开头的参数。例如，如果文件quit.ps只包含单词“ quit”，那么 -c quit在命令行上就相当于quit.ps那里。每个参数必须是有效的 PostScript，可以是由标记运算符定义的单个标记，也可以是包含有效 PostScript 的字符串。

-f将以下非开关参数解释为要使用普通run命令执行的文件名。由于这是默认行为，-f因此仅对终止 -c开关的令牌列表有用。

于 2013-07-10T12:29:30.930 回答
2

回答“为什么不使用 NumRenderingThreads”的问题。

情况很复杂 ：-）

PostScript 是一种解释性语言，只能作为单解释线程运行，因为状态可以随时更改，并且程序执行可以依赖于当前状态。由于您不能对解释器进行多线程处理，因此您需要从程序的开头开始并继续到结尾。

因此，为了运行线程，我们编写了一个“clist”，一种称为显示列表的形式。这不是解释的，它只不过是通过执行 PostScript 程序导出的输出页面上的图形基元和位置列表。注意 clist 是固定分辨率，原始 PostScript 程序不是，PostScript 程序可以根据它执行的环境采取不同的操作，clist 不能，等等。

然后，我们将输出页面拆分为水平条带，并使用 clist 为每个条带运行一个线程，以仅渲染位于该条带上的位。clist 允许多线程访问，并且因为它没有被解释，所以值不会改变。一些对象将横穿条纹，并将（部分）多次渲染（这对图像数据很重要）为了创建最终页面，我们将条纹缝合在一起。

这意味着总体而言，我们需要解释程序编写 clist，多次读取 clist 创建多个条带，然后我们需要将它们重新组合在一起。

或者，我们可以使用页面缓冲区，一块大到足以容纳整个输出的内存。我们解释一次，然后进行渲染。我们不编写 clist，我们只渲染每个对象一次，我们不需要合并输出。毫不奇怪，这更快。

那么 clist 和多个线程有什么意义呢？好吧，在高分辨率下，大多数系统没有足够的内存来一次性保存整个输出，所以我们必须生成条纹并将它们缝合在一起，这意味着我们需要一个 clist。如果我们必须走那条路，那么是的，NumRenderingThreads 会更快。

在 150 dpi 时，除非您为建筑物的侧面打印横幅，否则不太可能出现这种情况 :-)

所以 NumRenderingThreads可以更快，但在你的情况下它几乎可以肯定不是。但无论如何它可能是如此之快，以至于你无法分辨。

于 2013-07-10T13:35:52.110 回答
1

1) 不要使用 NumRenderingThreads。在 150 dpi 时，这只会减慢速度。

2）我们需要查看一个示例文件来发表评论。

3) 我真的看不出这将如何导致您的默认打印机开始发出页面。

从更简单的事情开始，是否：

gswin64c 输入.pdf

做任何事情 ？我希望打开一个窗口，显示 PDF 文件的第一页，按回车键将获得下一页，依此类推。

于 2013-07-10T11:53:37.590 回答