octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: wait_for_file ??


From: bpabbott
Subject: Re: wait_for_file ??
Date: Fri, 03 Sep 2010 21:11:35 +0000 (GMT)

On 03 Sep, 2010,at 03:56 PM, bpabbott <address@hidden> wrote:

On 03 Sep, 2010,at 12:34 PM, "John W. Eaton" <address@hidden> wrote:

On 3-Sep-2010, Michael D Godfrey wrote:

| On 09/03/2010 05:21 AM, Ben Abbott wrote:
|
| The approach in 1, has a problem. I'd intended that the __wait_for_file__ to be used when calling fig2dev, pstoedit (whose input is eps, so that's ok), and when appending pages which may be ps or pdf.
|
| Thus, using `drawnow("eps", filename)' won't work since the format may not be "eps", and we'd over-write the file we're waiting for.
|
| OK. So, it looks like it is necessary to find out why the *.eps write is not
| completed.

I'm coming into this a little late, so I might not understand all the
details. Actually, I can't even seem to find the beginning of the
thread as the first message I see with the subject "wait_for_file" is
a reply to another message that I can't locate
 
Michael and I had taken the discussion off line for in the hope of experimenting and documenting the problem .. things haven't worked out as hoped, so at some point we returned to the list.

As I understand the current print.m, the backend-specific print
function is supposed to generate a PostScript file that, if necessary,
will be processed by ghostscript to generate the specific output file
type that is desired. Correct? If so, then instead of generating a
file and dealing with possible race conditions, how about doing
something like

if (postprocess_with_gs)
fid = popen (gs command);
else if (send_to_printer)
fid = popen (lpr_command);
else if (write_to_postscript_file)
fid = fopen (ps_file_name);
else
error ("???");
endif

feval (backend_print_function, fid, opts);

Then the backend print function will just write its output to the open
file through fid.
 
I assume pstoedit and fig2dev can be handled in similar way.

However, I don't see how this fixes the problem. If the Gnuplot or GL2PS output file isn't present, how does this approach improve upon the current implementation.

.. or is the idea to write the EPS output directly to gs/pstoedit? ... if so, can that work when the EPS originates with Gnuplot?

If that's not possible, then is there some way to create a pipeline of
shell commmands so that we don't have to worry about whether writing
to the temporary intermediate file has been completed?

I'm confident this will work for gs, pstoedit, and fig2dev.
 
I'm asleep at the wheel :-( ... won't this approach still require the original eps file be written by Gnuplot or GL2PS?

Ben


reply via email to

[Prev in Thread] Current Thread [Next in Thread]