Re: wait_for_file ?? [epstool]

[Ben Abbott]

On Sep 5, 2010, at 7:19 PM, Ben Abbott wrote:

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

Adding a epstool would also allow tiff or interchange preview to be added to 
eps files (Matlab allow for tiff preview).

Ben