Groups > comp.lang.postscript > #1159 > unrolled thread

How can I overwrite existing files with new input to running Ghostscript?.

Started by	Ernie Kent <ernie@erniekent.com>
First post	2012-12-09 10:14 -0800
Last post	2012-12-24 19:37 -0800
Articles	5 on this page of 25 — 6 participants

Back to article view | Back to comp.lang.postscript

Page 2 of 2 — ← Prev page 1 [2]

#1185

From	Ernie Kent <ernie@erniekent.com>
Date	2012-12-22 09:00 -0800
Message-ID	<1e6eabe2-d9e0-49c0-926f-11beaab9ee0a@googlegroups.com>
In reply to	#1183

On Saturday, December 22, 2012 3:53:55 AM UTC-5, SaGS wrote:
> On 22 dec., 07:40, Ernie Kent <er...@erniekent.com> wrote:
> 
> > ...
> 
> > Although it overwrites the output, it doesn't actually change the file
> 
> > until GS is terminated.
> 
> > ...
> 
> > I've tried using both flushfile and closefile after showpage in your routine,
> 
> > but I can't find a way to specify the outputfile to these operators that
> 
> > doesn't give an error.
> 
> > ...
> 
> 
> 
> The output file is available after the "restore" (there where I
> 
> inserted code to print a message), the "showpage" in not sufficient.
> 
> This is what should happen, and on Windows at least this is actually
> 
> happening (I even used the Process Monitor and seen it closes the
> 
> file); I cannot try on Linux.
> 
> 
> 
> I don't know how you sync your program and GS, but in case you expect
> 
> to have the output file available when GS sends the ">>showpage, press
> 
> <return> to continue<<" message that's certainly not OK.

Thank you, SaGS

I am starting a Linux daemon to act as a GS server process. It runs GS as a background process and sends GS its stdin through a pipe. In turn the server process receives these inputs from any client process through a named fifo. 

Once the server daemon has started GS like this:

        $process = proc_open('gs -dBATCH -dNOPAUSE -sDEVICE=nullpage -', $descriptorspec, $pipes, $cwd);

it sends it the intialization you prescribed thus:

        if (is_resource($process)) {
                //Initialize gs output device
                 fwrite($pipes[0], "/SetMyDevice {
                    [
                        /OutputFile (/home/warp/public_html/spawn/out.jpg)
                        /HWResolution [128 128]
                        /PageSize [560 72]
                        /TextAlphaBits 4
                        /GraphicsAlphaBits 4
                    /jpeg findprotodevice copydevice putdeviceprops setdevice
                } bind def\n");
                fflush($pipes[0]);

After that it enters a loop waiting for fifo inputs from clients and sending them to GS in this fashion:

                //Begin while
                while ($out != "END") {

                //Here block on read from named fifo
                $file = fopen("/tmp/fifotest","r"); //Get ready to read the input from fifo
                $out = fread($file,"1000");             //read it
                fclose($file);

                //Tell gs to write something

                        fwrite($pipes[0], "
                        userdict /MyFiLeLeVeLsAvE save put
                            SetMyDevice
                                /Times-Bold 20 selectfont
                                3 10 moveto
                                ($out) show
                                showpage
                        cleardictstack clear MyFiLeLeVeLsAvE restore
                        \n");
                         fflush($pipes[0]);
                } //End while

This all works in the sense that the client can send multiple Postscript files to the server and GS will write each of them successively to the same jpeg file so that if GS is terminated at any point the last postscript input sent is then the image seen in the contents of the jpeg file.

However, no image is actually written to the file until GS is terminated. Since the "restore" is included in the loop, I suppose this may be a Linux/Windows difference. I was trying to put a postscript "<file> flushfile" or even "<file> closefile" following the "showpage" but it seems that was incorrect and I will try it following the restore as you indicate. I was, however, unable to figure out how to specify <file> correctly in the context of the code you provided. "OutputFile" for example gave a type error. What would I use for <file> in this case?

Thank you again for your help; it is most appreciated.

Ernie

[toc] | [prev] | [next] | [standalone]

#1186

From	Ernie Kent <ernie@erniekent.com>
Date	2012-12-22 19:37 -0800
Message-ID	<fdfb2faa-a083-46eb-a222-e7154325419c@googlegroups.com>
In reply to	#1185

On Saturday, December 22, 2012 12:00:36 PM UTC-5, Ernie Kent wrote:
> On Saturday, December 22, 2012 3:53:55 AM UTC-5, SaGS wrote:
> 
> > On 22 dec., 07:40, Ernie Kent <er...@erniekent.com> wrote:
> 
> > 
> 
> > > ...
> 
> > 
> 
> > > Although it overwrites the output, it doesn't actually change the file
> 
> > 
> 
> > > until GS is terminated.
> 
> > 
> 
> > > ...
> 
> > 
> 
> > > I've tried using both flushfile and closefile after showpage in your routine,
> 
> > 
> 
> > > but I can't find a way to specify the outputfile to these operators that
> 
> > 
> 
> > > doesn't give an error.
> 
> > 
> 
> > > ...
> 
> > 
> 
> > 
> 
> > 
> 
> > The output file is available after the "restore" (there where I
> 
> > 
> 
> > inserted code to print a message), the "showpage" in not sufficient.
> 
> > 
> 
> > This is what should happen, and on Windows at least this is actually
> 
> > 
> 
> > happening (I even used the Process Monitor and seen it closes the
> 
> > 
> 
> > file); I cannot try on Linux.
> 
> > 
> 
> > 
> 
> > 
> 
> > I don't know how you sync your program and GS, but in case you expect
> 
> > 
> 
> > to have the output file available when GS sends the ">>showpage, press
> 
> > 
> 
> > <return> to continue<<" message that's certainly not OK.
> 
> 
> 
> Thank you, SaGS
> 
> 
> 
> I am starting a Linux daemon to act as a GS server process. It runs GS as a background process and sends GS its stdin through a pipe. In turn the server process receives these inputs from any client process through a named fifo. 
> 
> 
> 
> Once the server daemon has started GS like this:
> 
> 
> 
>         $process = proc_open('gs -dBATCH -dNOPAUSE -sDEVICE=nullpage -', $descriptorspec, $pipes, $cwd);
> 
> 
> 
> it sends it the intialization you prescribed thus:
> 
> 
> 
>         if (is_resource($process)) {
> 
>                 //Initialize gs output device
> 
>                  fwrite($pipes[0], "/SetMyDevice {
> 
>                     [
> 
>                         /OutputFile (/home/warp/public_html/spawn/out.jpg)
> 
>                         /HWResolution [128 128]
> 
>                         /PageSize [560 72]
> 
>                         /TextAlphaBits 4
> 
>                         /GraphicsAlphaBits 4
> 
>                     /jpeg findprotodevice copydevice putdeviceprops setdevice
> 
>                 } bind def\n");
> 
>                 fflush($pipes[0]);
> 
> 
> 
> After that it enters a loop waiting for fifo inputs from clients and sending them to GS in this fashion:
> 
> 
> 
>                 //Begin while
> 
>                 while ($out != "END") {
> 
> 
> 
>                 //Here block on read from named fifo
> 
>                 $file = fopen("/tmp/fifotest","r"); //Get ready to read the input from fifo
> 
>                 $out = fread($file,"1000");             //read it
> 
>                 fclose($file);
> 
> 
> 
>                 //Tell gs to write something
> 
> 
> 
>                         fwrite($pipes[0], "
> 
>                         userdict /MyFiLeLeVeLsAvE save put
> 
>                             SetMyDevice
> 
>                                 /Times-Bold 20 selectfont
> 
>                                 3 10 moveto
> 
>                                 ($out) show
> 
>                                 showpage
> 
>                         cleardictstack clear MyFiLeLeVeLsAvE restore
> 
>                         \n");
> 
>                          fflush($pipes[0]);
> 
>                 } //End while
> 
> 
> 
> This all works in the sense that the client can send multiple Postscript files to the server and GS will write each of them successively to the same jpeg file so that if GS is terminated at any point the last postscript input sent is then the image seen in the contents of the jpeg file.
> 
> 
> 
> However, no image is actually written to the file until GS is terminated. Since the "restore" is included in the loop, I suppose this may be a Linux/Windows difference. I was trying to put a postscript "<file> flushfile" or even "<file> closefile" following the "showpage" but it seems that was incorrect and I will try it following the restore as you indicate. I was, however, unable to figure out how to specify <file> correctly in the context of the code you provided. "OutputFile" for example gave a type error. What would I use for <file> in this case?
> 
> 
> 
> Thank you again for your help; it is most appreciated.
> 
> 
> 
> Ernie

LATER: -- I think I now have a handle on what is happening.

1. If I manually start gs from the shell and enter the commands of your script, there is no write to file until after I stop gs.

2. If I enter this part of the script, 
                       userdict /MyFiLeLeVeLsAvE save put
                            SetMyDevice
                                /Hacknslash 20 selectfont
                                3 10 moveto
                                (First) show
                                showpage
                        cleardictstack clear MyFiLeLeVeLsAvE restore
(the part that was in my loop) and after that I then enter it a second time without kiling gs, gs writes output to the file TWICE. Thereafter it writes once for each time I enter that part of the script. In this case I am entering all commands directly to the gs stdin. I have no clue why it behaves this way.

3. If I operate gs via a deamon process through fifos and pipes, something similar occurs except that in this case gs writes to file only after FIVE iterations of the input script, and then each time thereafter.

This gives me a workaround klluge; just initialize it with fivr writes. I'd feel much more comfortable however if I understood why it is behaving this way.

Ernie

[toc] | [prev] | [next] | [standalone]

#1187

From	Chris <cjl@spamcop.net>
Date	2012-12-23 17:16 +0000
Message-ID	<E%GBs.973866$vW7.753483@fx19.am4>
In reply to	#1186

On Sat, 22 Dec 2012 19:37:06 -0800, Ernie Kent wrote:

> 
> LATER: -- I think I now have a handle on what is happening.
> 
> 1. If I manually start gs from the shell and enter the commands of your
> script, there is no write to file until after I stop gs.
> 
> 2. If I enter this part of the script,
>                        userdict /MyFiLeLeVeLsAvE save put
>                             SetMyDevice
>                                 /Hacknslash 20 selectfont 3 10 moveto
>                                 (First) show showpage
>                         cleardictstack clear MyFiLeLeVeLsAvE restore
> (the part that was in my loop) and after that I then enter it a second
> time without kiling gs, gs writes output to the file TWICE. Thereafter
> it writes once for each time I enter that part of the script. In this
> case I am entering all commands directly to the gs stdin. I have no clue
> why it behaves this way.
> 
> 3. If I operate gs via a deamon process through fifos and pipes,
> something similar occurs except that in this case gs writes to file only
> after FIVE iterations of the input script, and then each time
> thereafter.
> 
> This gives me a workaround klluge; just initialize it with fivr writes.
> I'd feel much more comfortable however if I understood why it is
> behaving this way.

The file object should be associated with the device, so once the device 
closes and unloads (which in this case is prompted by the restore), the 
file should be closed and the object released.

A few things spring to mind: there is a "ReopenPerPage" device parameter 
which (in theory!) forces the output file to be closed an reopened after 
each page. You could try adding "/ReopenPerPage true" to the page device 
dictionary and see if that helps.

Possibly give gs a *different* output file name on the command line to 
the one you pass in in the Postscript stream (or start gs with -
dNODISPLAY). Some devices open the output file on initialisation, and 
keep it open until it either moves onto the next page, or the device 
closes.

Thirdly, try initialising gs with a different device to the one you 
actually was to get output from (again, -dNODISPLAY would work), in case 
there is an issue with multiple instances of the same device ending up 
sharing output file objects.

It's always possible you've found a bug (for example, in Postscript 
terms, the output filter may not be setup to close the underlying file 
object when the filter itself is closed), in which case you can report a 
bug, and we'll look into it.

Chris

[toc] | [prev] | [next] | [standalone]

#1188

From	SaGS <sags5495@gmail.com>
Date	2012-12-23 10:16 -0800
Message-ID	<cfd27480-0dc9-4175-b750-59a2b5ec15c6@b8g2000yqh.googlegroups.com>
In reply to	#1186

On Dec 23, 5:37 am, Ernie Kent <er...@erniekent.com> wrote:
> ...
> > This all works in the sense that the client can send multiple
> > Postscript files to the server and GS will write each of
> > them successively to the same jpeg file so that if GS is
> > terminated at any point the last postscript input sent is
> > then the image seen in the contents of the jpeg file.
> >
> > However, no image is actually written to the file until GS
> > is terminated.
> ...
> 1. If I manually start gs from the shell and enter the commands
> of your script, there is no write to file until after I stop gs.
> ...

I agree with Chris, after the "restore" the outfile should be written
and closed, unless there's a bug somewhere.

I used Ubuntu with GS 8.61, and checked open files with "ls -l /proc/
<pid>/fd". Once GS starts, only stdin/out/err are open. After
"showpage" I see "out.jpg" opened too. After "restore" (without
quitting GS or doing anything else) "out.jpg" isn't open anymore, and
I can view the jpeg verifying its contents is what I expect it to be.

I still suspect you have some trouble with syncing the various
programs you run.

You have client(s) <-> daemon <-> gs. The/A client writes some info to
trigger creating a new jpeg, but it takes time for the daemon to "see"
that info and write to the pipe that connects it to GS. Then, the
daemon flushes the write end of the pipe and continues checking for
new requests from the client(s), but that does not mean GS had a
chance to read all the code for the 1st request and execute it to
completion. With your scheme, I don't see how the client can know if/
when GS actually finished what it had to do (execute everything up to
and including the "restore", and nothing more).

If it will turn out the problems are with this syncing, then it is not
something connected to PostScript or Ghostscript.

[toc] | [prev] | [next] | [standalone]

#1190

From	luser- -droog <mijoryx@yahoo.com>
Date	2012-12-24 19:37 -0800
Message-ID	<307b7d53-9ff3-4dfd-9eb2-fdce16e4bb85@googlegroups.com>
In reply to	#1188

On Sunday, December 23, 2012 12:16:54 PM UTC-6, SaGS wrote:
> On Dec 23, 5:37 am, Ernie Kent <er...@erniekent.com> wrote:
> > ...
> > > This all works in the sense that the client can send multiple
> > > Postscript files to the server and GS will write each of
> > > them successively to the same jpeg file so that if GS is
> > > terminated at any point the last postscript input sent is
> > > then the image seen in the contents of the jpeg file.
> > > 
> > > However, no image is actually written to the file until GS
> > > is terminated.
> > ...
> > 1. If I manually start gs from the shell and enter the commands
> > of your script, there is no write to file until after I stop gs.
> > ...
> I agree with Chris, after the "restore" the outfile should be written
> and closed, unless there's a bug somewhere.
> I used Ubuntu with GS 8.61, and checked open files with "ls -l /proc/
> <pid>/fd". Once GS starts, only stdin/out/err are open. After
> "showpage" I see "out.jpg" opened too. After "restore" (without
        >
        > quitting GS or doing anything else) "out.jpg" isn't open anymore, and
> I can view the jpeg verifying its contents is what I expect it to be.
> I still suspect you have some trouble with syncing the various
> programs you run. 
> You have client(s) <-> daemon <-> gs. The/A client writes some info to
> trigger creating a new jpeg, but it takes time for the daemon to "see"
> that info and write to the pipe that connects it to GS. Then, the
> daemon flushes the write end of the pipe and continues checking for
> new requests from the client(s), but that does not mean GS had a
> chance to read all the code for the 1st request and execute it to
> completion. With your scheme, I don't see how the client can know if/
> when GS actually finished what it had to do (execute everything up to
        >
        > and including the "restore", and nothing more).
> If it will turn out the problems are with this syncing, then it is not
> something connected to PostScript or Ghostscript.


You could trying having ghostscript write an "I'm done!" message to a named pipe listened to by the "client".

(not tested)

    (gsmon.fifo)file dup(EOP\n)writestring closefile

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

csiph-web

How can I overwrite existing files with new input to running Ghostscript?.

Contents

#1185

#1186

#1187

#1188

#1190