0

入力pdfを一連の出力PNG画像（ページごとに1つの画像）に変換する目的で呼び出す次のGhostScriptコマンドがあります。

"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 画像も生成しません。

UPDATE を省略すると、次のようになり-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 のおかげで、次のパラメーターが破損していることを確認するまで、一度に 1 つのパーツを削除しました。

-c "30000000 setvmthreshold"

GSの速度を改善しようとして、別のフォーラムでこれを入手しました。使い方が間違っていますか、それともそのままにしておくべきですか? PDF は非常に大きく、数百ページにも及ぶため、可能な限り最適化する必要があります。助言がありますか？

誰かが私を正しい方向に向けることができますか? ありがとう

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

次のHow to use Ghostscriptから、それが明らかになるはずです。

-c string ...- " " で始まり、その後に数字以外の文字が続く、または " "で始まる次の引数まで、引数を PostScript コードとして解釈します@。たとえば、ファイルに " " quit.psという単語だけが含まれている場合、コマンド ラインの on はthere と同じです。各引数は、有効な PostScript である必要があります。トークン オペレータによって定義された個々のトークン、または有効な PostScript を含む文字列のいずれかです。quit-c quitquit.ps

-f次の非スイッチ引数を、通常のrunコマンドを使用して実行されるファイル名として解釈します。これはデフォルトの動作であるため、スイッチ-fのトークンのリストを終了する場合にのみ役立ち ます。-c

于 2013-07-10T12:29:30.930 に答える
2

Answering the 'why not to use NumRenderingThreads' question.

Its complicated :-)

PostScript is an interpreted language and can only be run as a single thread of interpretation because the state can change as you go, and program execution can rely on the current state. Since you cannot multi-thread the interpreter you need to start at the beginning of the program and proceed to the end.

So, in order to run threads, we write a 'clist' a form of what's known as a display list. This isn't interpreted, its little more than a list of graphic primitives and positions on the output page which is derived by executing the PostScript program. NB the clist is a fixed resolution, the original PostScript program isn't, the PostScript program can take different actions depending on the environment it executes in, the clist can't, etc.

We then split the output page into horizontal stripes and use the clist to run one thread per stripe to render just the bits that lie on that stripe. The clist allows multiple thread access and because its not interpreted, values don't change. Some objects will lie across striped and will be (partially) rendered multiple times (this is important for image data) In order to create the final page we stitch the stripes back together.

This means that overall we need to interpret the program write the clist, read the clist multiple times creating multiple stripes, which we then need to put back together.

Alternatively we can use a page buffer, a chunk of memory large enough to hold the entire output. We interpret once, and render as we go. We don't write a clist, we only render each object once and we don't need to consolidate the outputs. Not surprisingly this is faster.

So what's the point of a clist and multiple threads ? Well at high resolution most systems don't have enough memory to hold the entire output in one go, so we have to produce stripes and stitch them together, which means we need a clist. If we have to go down that route then yes, NumRenderingThreads will be faster.

At 150 dpi, unless you are printing banners for the sides of buildings, this is unlikely to be the case :-)

So NumRenderingThreads can be faster, but in your case it almost certainly isn't. But it may be so fast anyway that you can't tell.

于 2013-07-10T13:35:52.110 に答える