CODEWITHSUNDEEP
pdfghostscript
hofnarwillie
hofnarwillie

Reputation: 3660

Ghostscript printing out a bunch of encoded chars when trying to convert to PNG

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" \
    "C:\input.pdf"

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.
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

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

Upvotes: 0

Views: 693

Answers (3)

KenS
KenS

Reputation: 31139

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.

Upvotes: 2

devnull
devnull

Reputation: 123478

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.

-f Interprets following non-switch arguments as file names to be executed using the normal run command. Since this is the default behavior, -f is useful only for terminating the list of tokens for the -c switch.

Upvotes: 3

KenS
KenS

Reputation: 31139

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.

Upvotes: 1

Related Questions