Take the 2-minute tour ×

I have the following GhostScript command that I call with the intention of converting the input pdf to a bunch of output PNG images (one image per page):

"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" \

When I run this command in the Windows Command Prompt it suddenly prints out a load of papers with a bunch of encoded characters from my default printer. It doesn't produce any sort of PNG images.

UPDATE Omitting -q gives:

GPL Ghostscript 9.07 (2013-02-14)
Copyright (C) 2012 Artifex Software, Inc.  All rights reserved.
Processing pages 1 through 4.
Page 1
Page 2
Page 3
Page 4

UPDATE 2: Thanks to KenS, I removed one part at a time until confirming that it is the following parameter that breaks it:

-c "30000000 setvmthreshold"

I got this on a different forum trying to improve the speed of GS. Am I using it wrong or should I just leave it out? The PDF's are going to be very large and with 100's of pages, so I need to optimize as much as possible. Any suggestions?

Can anyone point me in the right direction? Thanks

share|improve this question
Do you get any helpful information if you omit -q from the command line? –  devnull Jul 10 '13 at 11:53
@devnull: Plz check the update to the post. –  hofnarwillie Jul 10 '13 at 12:13
try a fixed, unquoted name for the output file -sOutputFile=test.png (could be an issue with quoting the % .. ) –  agentp Jul 10 '13 at 12:24

3 Answers 3

up vote 3 down vote accepted

I believe that rewriting your command line so as to change the order of arguments and adding -f to denote the input file should make it work:

"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

The following from How to use Ghostscript should make it apparent:

-c string ... Interprets arguments as PostScript code up to the next argument that begins with "-" followed by a non-digit, or with "@". For example, if the file quit.ps contains just the word "quit", then -c quit on the command line is equivalent to quit.ps there. Each argument must be valid PostScript, either individual tokens as defined by the token operator, or a string containing valid PostScript.


share|improve this answer
Thanks! Like a charm... –  hofnarwillie Jul 10 '13 at 12:40
@hofnarwillie Great! –  devnull Jul 10 '13 at 12:56
good call -- in the original the -c is terminated by -dNumRenderingThreads so its not clear whats wrong per the docs.. –  agentp Jul 10 '13 at 13:08

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.

share|improve this answer
I see (or not). It IS complicated. I'll just take your word for it. Thank you for the clarification. –  hofnarwillie Jul 10 '13 at 15:27

1) Don't use NumRenderingThreads. At 150 dpi this will only slow things down.

2) We'd need to see an example file to comment much.

3) I can't really see how this would cause your default printer to start emitting pages.

Start with something simpler, does :

gswin64c input.pdf

do anything ? I'd expect a window to open displaying the first page of the PDF file, pressing return will get you the next page and so on.

share|improve this answer
Thank you for the suggestions. Please see the update to the post. –  hofnarwillie Jul 10 '13 at 12:14
As well as the update in my post, could you tell me why you say NumRenderingThreads will slow things down. Using multiple threads should surely only speed things up, no? –  hofnarwillie Jul 10 '13 at 12:18
This is where I got it from. ghostscript.com/doc/current/Use.htm#Improving_performance Am I misunderstanding this??? –  hofnarwillie Jul 10 '13 at 12:39

Your Answer


