When attempting to create an image from a pdf file, instead of
creating the output file, data is sent to the printer. Why?

Here's my command line:

C:\Documents and Settings\me\Desktop>"c:\program files\gs\gs9.00\bin
\gs
win32c" -dBATCH -dNOPAUSE -sDEVICE=png16m -dPrinted=false -
sOutputfile='c:\yadda
1.png' xl1.pdf

Thanks very much.

On Oct 12, 3:58=A0pm, johnniec <jpcart...@gmail.com> wrote:
> When attempting to create an image from a pdf file, instead of
> creating the output file, data is sent to the printer. Why?
>
> Here's my command line:
>
> C:\Documents and Settings\me\Desktop>"c:\program files\gs\gs9.00\bin
> \gs
> win32c" -dBATCH -dNOPAUSE -sDEVICE=3Dpng16m -dPrinted=3Dfalse -
> sOutputfile=3D'c:\yadda
> 1.png' xl1.pdf
>
> Thanks very much.

I've never heard of -dPrinted.
I'd recommend adding the gs/bin to your path to avoid all that typing
and quoting. It looks like you may have a space between the hyphen
and sOutputfile. It it were me, I'd try somehow to stick to
directories and files without spaces in them. It's difficult to
see what the problem may be without seeing the output, unwrapped.
I'm also not sure how whatever-os-this-is interprets single quotes.

If you do have a space between the hyphen and sOutputFile (should be
a big 'F', too, btw), then hyphen is interpreted to mean "read the
standard input file first before any other files mentioned further
on in the command line", sOutputfile=3Dwhatever could be interpreted
by shell to set a variable (maybe?) or ghostscript could see the
whole thing and look for a file by that name (it would probably
display an error message if this was the case).

To sum up, spaces and quoting are confusing the situation.
Get rid of them somehow.
Make sure the hyphen for an option is touching the rest of the
option.
Copy more of the session transcript (including any and all messages
ghostscript prints to the screen).

And what's your source for this -dPrinted option?

--
lxt

On Oct 12, 10:08=A0pm, luserXtrog <mijo...@yahoo.com> wrote:
> On Oct 12, 3:58=A0pm, johnniec <jpcart...@gmail.com> wrote:
>
> > When attempting to create an image from a pdf file, instead of
> > creating the output file, data is sent to the printer. Why?
>
> > Here's my command line:
>
> > C:\Documents and Settings\me\Desktop>"c:\program files\gs\gs9.00\bin
> > \gs
> > win32c" -dBATCH -dNOPAUSE -sDEVICE=3Dpng16m -dPrinted=3Dfalse -
> > sOutputfile=3D'c:\yadda
> > 1.png' xl1.pdf
>
> > Thanks very much.
>
> I've never heard of -dPrinted.
> I'd recommend adding the gs/bin to your path to avoid all that typing
> and quoting. It looks like you may have a space between the hyphen
> and sOutputfile. It it were me, I'd try somehow to stick to
> directories and files without spaces in them. It's difficult to
> see what the problem may be without seeing the output, unwrapped.
> I'm also not sure how whatever-os-this-is interprets single quotes.
>
> If you do have a space between the hyphen and sOutputFile (should be
> a big 'F', too, btw), then hyphen is interpreted to mean "read the
> standard input file first before any other files mentioned further
> on in the command line", sOutputfile=3Dwhatever could be interpreted
> by shell to set a variable (maybe?) or ghostscript could see the
> whole thing and look for a file by that name (it would probably
> display an error message if this was the case).
>
> To sum up, spaces and quoting are confusing the situation.
> Get rid of them somehow.
> Make sure the hyphen for an option is touching the rest of the
> option.
> Copy more of the session transcript (including any and all messages
> ghostscript prints to the screen).
>
> And what's your source for this -dPrinted option?
>
> --
> lxt

Thanks very much for helping me solve the problem. The problem was I
had:
-sOutputfile
When it should have been:
-sOutputFile

This is on Windows XP.  Also, it didn't like the single quotes
but is perfectly happy with double quotes.  Once the first
problem was fixed I got a reasonable response that made the
quotes obvious.

Minor rant: Ghostscript could have done much better by
parsing the command line and responding with a warning on
anything it can't interpret or anything that doesn't make
sense.

In article <00cc638a-222a-4f75-84b7-5a583e3e80f8
@n7g2000vbo.googlegroups.com>, jpcarter1@gmail.com says...

> Minor rant: Ghostscript could have done much better by
> parsing the command line and responding with a warning on
> anything it can't interpret or anything that doesn't make
> sense.

Can't be done. The command line can and does contain aribtrary 
PostScript. Even the -d/-s switches merely set values in PostScript 
dictionaries which are only used when the relevant device wants them.

So you can type -sYADAYADAYA=NOTHING without getting an error, but 
unless you have a device which reads an entry called /YADAYADAYADA from 
systemdict, nothing will happen. Of course the entry is still there, and 
you can write a PostScript program which interrogates it and uses the 
value.

So these forms of switches can't be verified.


			Ken