octave-maintainers
[Top][All Lists]
Advanced

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

Re: unified FLTK & Gnuplot printing


From: Shai Ayal
Subject: Re: unified FLTK & Gnuplot printing
Date: Mon, 30 Aug 2010 17:27:34 +0300

On Mon, Aug 30, 2010 at 5:23 PM, bpabbott <address@hidden> wrote:
> On 30 Aug, 2010,at 09:51 AM, John Swensen <address@hidden> wrote:
>
> On Aug 23, 2010, at 9:13 PM, Ben Abbott wrote:
>
>> I've prepared a changeset to unify the printing for both the FLTK and
>> Gnuplot backends.
>>
>> For both backends, ghostscript is relied upon more heavily than before.
>> Ghostscript is used to produce most output formats from an eps image of the
>> figure. The output formats based upon an eps image are bmp, jpg, pbm, pcx,
>> pdf, pgm, pgn, pnm, ppm, ps, and tiff. Using an eps image as the basis for
>> most output formats allow all those formats to benefit from efforts invested
>> in eps output.
>>
>
> On a somewhat related note, are the changes specific to FLTK and Gnuplot, or
> does it apply to any OpenGL based backend and Gnuplot? The reason I ask is
> because Michael Goffioull and I (mostly Michael) have been working on a
> GTK/OpenGL backend and I wonder how much of the FLTK improvements will apply
> to all OpenGL based backend.
>
> John Swensen
>
>
> I'm not very familiar with the architecture. So, I've cc'd Shai in case I
> get something wrong
> My understanding is that the printed output is produced using GL2PS, which
> is not part of FLTK and should (could?) work with any OpenGL
> renderer/backend.
> You can look at the ChangeLog for fltk_backend.cc to see what changes have
> been done there ...
>
>  
> http://hg.savannah.gnu.org/hgweb/octave/log/015ba76371b9/src/DLD-FUNCTIONS/fltk_backend.cc
> From what I infer, the FLTK backend calls GL2PS in order to produce the
> desired output. I assume it is straight forward to do the same for other
> OpenGL backends. In which case all the printing features available for the
> FLTK backend would apply to other OpenGL implementations.
> Ben
>
Again you beat me to it!

Anyway, all the m-file based improvements should port over easily as
long as you can produce eps output.
Things which are c++ based (i.e. getting the figure bitmap directly,
producing the eps) should be re-implemented for the other backends.

Shai



reply via email to

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