[gs-devel] pdfwrite and stdio

[Ken Sharp]

At 08:20 30/03/2009 -0400, Yvan Rodrigues wrote:

>The documentation is misleading in this regard.

Well, I guess the problem is that there are two different kinds of 
documentation, for two different purposes. I can'[[t say I'm happy with our 
documentation, but I'm not volunteering to rewrite it either, so I'm not 
really in a position to criticise ;-)

However, as a relative newcomer to Ghostscript, I've found it difficult to 
get to grips with at times....


>     - The main gs docs explain how -sOutputFile=- and 
> -sOutputFile=%stdout work. It remarks that if gs is asked to parse a PDF 
> file that it will read the entire document at once due to the random 
> access requirement. This is of course a separate issue from output devices.
>     - In the "selecting an output device" section there is no distinction 
> between gs's stdio streams and the OS's streams.

These parts of the documentation refer to the standard Ghostscript 
application rather than the 'developer' gsapi interface. I guess you could 
say this is 'user' documentation.


>     - The pdfwrite docs make no mention of -sOutputFile=-. Googling 
> "pdfwrite stdout" results in a couple of examples of doing this, though I 
> can't say I've tried.

Quite correct I'd never heard of it either, and I'm the pdfwrite maintainer...

However it *is* documented in /gs/doc/use.htm, section 4 'Interacting with 
pipes'. The ps2pdf documentation is supplemental to the general Ghostscript 
documentation I'm afraid, not stand-alone, it basically tells you where the 
pdfwrite device differs from the standard.


>     - The gsapi docs say "When using the Ghostscript interpreter library 
> interface, you have a choice of two standard input/output methods. If you 
> do nothing, the "C" stdio will be used. If you use gsapi_set_stdio(), all 
> stdio will be redirected to the callback functions you provide. This 
> would be used in a graphical user interface environment where stdio is 
> not available, or where you wish to process Ghostscript input or output."

OK, this is developer documentation, which is different to the user stuff. 
The hidden assumption here is that you are doing all the input and output 
from GS yourself, rather than using our input code and one of our devices. 
So the  stdio referred to is, I believe, the PostScript input and output.

That is when the PostScript environment has consumed a buffer of data it 
goes to stdin for more, if you've redirected stdin then it goes to your 
routines instead. If the PostScript environment needs to send data on the 
back channel, then it will use stdout or stderr, if you've redirected those 
then it calls your routines.

These affect only the PostScript environment, not the OS (or C if you 
prefer) environment.


>For what it's worth, when I did try to use pdfwrite to output to stdout 
>using gsapi, it did successfully write something that resembled a PDF (in 
>as much as there was a start tag and then some mixed text and binary) but 
>when gsapi_exit was called the thread would hang. When I debugged it, it 
>hung during a final attempt to flush the stream. This is in a 32-bit 
>Windows environment.

You got better results than me :-(


>Ken are you suggesting that even a named pipe (or any stream) would not 
>work? There is no way of doing this as an in-memory operation without 
>emulating a filesystem?

Well, it didn't work for me on Windows, I'd have to debug it to find out 
exactly why. I'm unsure of the detail on how this stuff works even on Unix 
because I've never had any call to investigate it.

A quick inspection suggests that there is no magic, so it ought to work on 
Windows as well as Unix. It is alternatively possible that a temporary file 
is created, and when complete is read back to stdout, but I don't *think* 
that is happening.

Going back to the documentation, the section I mentioned above states quite 
clearly that GS will write to pipes and certainly indicates it will work on 
Windows systems, since it specifically mentions doubling the '%' characters.

I can only suggest you try it and see. If you really can't get pdfwrite to 
work with stdout on Windows, then I recommend you open a bug report about 
it, it looks like it should (though that begs the question of why the 
Windows ps2pdf batch file doesn't offer the option) and it certainly did 
when I used Fedora.


                         Ken