octave-maintainers
[Top][All Lists]
Advanced

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

Re: wait_for_file ??


From: Shai Ayal
Subject: Re: wait_for_file ??
Date: Thu, 9 Sep 2010 20:26:29 +0300

On Thu, Sep 9, 2010 at 3:15 PM, Ben Abbott <address@hidden> wrote:
>
> 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?)

You got it :)

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

The cat is not needed. I just used it for the example.

Shai



reply via email to

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