Re: wait_for_file ??

[bpabbott]

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.

Also, looking at the current gnuplot and fltk print functions, it
seems like there is some duplication of code. I didn't expect to find
anything about ghostscript in either of those functions as I thought
the idea was to have them just generate PostScript and that
ghostscript would only be used by the calling function.

Can someone explain the design to me?

Thanks,

jwe

The design isn't what is could/should be.

The current status is a result of ...

(1) adding the ability to print using the FLTK backend (GL2PS), without changing the approach to Gnuplot printing.

(2) Modifying Gnuplot printing to be consistent with approached  used  for GL2PS.

I had considered trying to further reduce / eliminate duplicate code, but haven't gotten around to looking at the details yet. In any event, I think a discussion of the topic of how the printing should be designed is appropriate.

Another topic is duplication of function. Some output formats available natively from Gnuplot (fig for example) are derived from EPS for the GL2PS output. Should both approaches be supported, or should a single implementation based upon a lowest common denominator, of Gnuplot and GL2PS, be implemented.

Currently, the lowest common denominator would be EPS and EPSLaTeX output. Some formats, such as PGF/TikZ, would require special attention.

Ben