Re: wait_for_file ??

[Ben Abbott]

On Sep 9, 2010, at 7:35 AM, Shai Ayal wrote:

> On Thu, Sep 9, 2010 at 9:07 AM, Shai Ayal <address@hidden> wrote:
>> On Thu, Sep 9, 2010 at 6:33 AM, Michael D Godfrey
>> <address@hidden> wrote:
>>> On 09/08/2010 06:26 PM, Ben Abbott wrote:
>>> 
>>> I think jwe's suggestion of drawing to a piped gs rather than to a
>>>> file is the way to go. I'll try to implement the gl2ps part.
>>>> 
>>>> Shai
>>> 
>>> For gnuplot backend, the gnuplot eps file can be save to a tmp-file which
>>> can then be converted via the pipe.
>>> 
>>> However, for the opengl backends, the pipe approach will limit the formats
>>> to those available from gl2ps and those available from gs (pdf, ps, ps2, and
>>> many the bitmaps and printer languages). Am I correct?
>>> 
>>> Output formatted as dxf, emf, fig, hpgl, ai, pstex, mf, etc (all formats
>>> derived using pstoedit and fig2dev will no longer be available for opengl
>>> backends? .... If so I think it best to avoid using pstoedit, fig2dev, and
>>> epstool.
>>> 
>>> Should the "-tight" option will need to go as well?
>>> 
>>> As my questions indicate, I'm a bit cloudy on the implications. I'll be
>>> studying this approach for a while and plan to wait on Shai before
>>> contributing any significant changes.
>>> 
>>> Ben
>>> 
>>> 
>>> 
>>> This sounded good to me at first, but now I do not see how it is going to
>>> work.
>>> There must be something that ensures that routine glps_renderer::draw in
>>> gl2ps-renderer.cc
>>> really gets run when the code in __fltk_print__.m needs it.
>>> 
>>> I hope Shai and Ben have this figured out.
>>> 
>>> Michael
>> 
>> I think using a pipe will not make the render code run when we need
>> it, but at least it will make sure that gs is only called when the
>> data to convert is ready.
>> 
>> Shai
>> 
> 
> OK, I pushed the relevant changes to make fltk print to an fid
> **warning** this breaks current fltk printing!
> http://hg.savannah.gnu.org/hgweb/octave/rev/2786e3b7072e
> 
> to use, pass the fid as a string to drawnow:
> e.g. to keep current functionality, use
> fid = fopen ("test.eps","wb");
> drawnow ("eps" , sprintf ("%d" , fid));
> 
> and to pipe it into another program, use popen:
> fid = popen ("cat >  test.eps" , "w")
> drawnow ("eps" , sprintf ("%d" , fid));
> 
> Shai

Nice!

The last example gives me an idea (or am I just getting the gist of John's 
suggestion?)

Why not always use ... fid = popen ("cat ...")?

        fid = popen (pipeline, "w")

where `pipeline' is a string containing a piped command line. Which could be 
just gs. For "print test.jpg" ...

        pipeline = "cat | gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=jpeg 
-dTextAlphaBits=4 -dGraphicsAlphaBits=4 -r150x150 -dEPSCrop 
-sOutputFile=test.jpg"

For fig ..

        pipeline = "cat | pstoedit -f fig test.fig"

For emf ...

        pipeline = "cat | pstoedit -f fig | fig2dev -L emf test.emf"

I'm not sure the "cat" is needed except in Shai's example, but you using this 
approach a pipeline of conversions can be implemented.

This can be implemented by modifying __ghostscript__ to return, but not 
execute, the gs command. The same for __pstoedit__ and __fig2dev__ (which are 
currently in __fltk_print__).

Once the entire pipe line is constructed the result can be called in print.m

For the gnuplot backend, the original eps file can be written as a temporary 
file and then ...

        pipleline = "cat /var/tmp/oct-ghVmSK.eps | pstoedit ..."

Ben