octave-maintainers
[Top][All Lists]
Advanced

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

Re: wait_for_file ??


From: Ben Abbott
Subject: Re: wait_for_file ??
Date: Sun, 05 Sep 2010 19:19:34 -0400

On Sep 3, 2010, at 12:34 PM, John W. Eaton 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.
> 
> 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.

As I was working on eliminating duplication of code in __gnuplot_print__ and 
__fltk_print__ it occured to me that using that approach would be a problem for 
the "-tight" option.

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

Creating a pipeline can work, if epstool (or something functionallly 
equivalent) is added.

Any objection to requiring epstool be available for the "-tight" option?

Ben



reply via email to

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