[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
- Re: wait_for_file ?? [GL2PS error: Bad file pointer], (continued)
- Re: wait_for_file ??, Ben Abbott, 2010/09/09
- Re: wait_for_file ??, Ben Abbott, 2010/09/04
- Re: wait_for_file ??, Ben Abbott, 2010/09/06
- Re: wait_for_file ??, Michael D Godfrey, 2010/09/06
- Re: wait_for_file ??, Ben Abbott, 2010/09/06
- Re: wait_for_file ??, Ben Abbott, 2010/09/08
- Re: wait_for_file ??,
Ben Abbott <=
- Re: wait_for_file ?? [epstool], Ben Abbott, 2010/09/05
- Re: wait_for_file ?? [epstool], Michael D Godfrey, 2010/09/05
- Re: wait_for_file ??, Michael D Godfrey, 2010/09/03