Re: Proposal: Saving graphs from Qt and wxt terminals

[Ethan M. <merritt@u.washington.edu>]

On Saturday, 25 October 2014 01:26:53 PM Philipp K. Janert wrote:
> On Sat, 25 Oct 2014 16:09:49 -0400 (EDT)
> Allin Cottrell <cot...@wf...> wrote:
> 
> > On Fri, 24 Oct 2014, Philipp K. Janert wrote:
> > 
> > >> One thing to be careful of is the fact that saving to PDF (which is
> > >> certainly welcome in my opinion because the first word of PDF means
> > >> "portable") in the Qt terminal isn't using the PDF terminal.  There
> > >> are no colors in the PDF output via Qt, whereas the PDF terminal
> > >> creates a PDF output with colors.  Do we want as setup in which the
> > >> interactive terminals use the PDF terminal, or a setup in which the
> > >> interactive terminals use their own custom PDF output?
> > >
> > > I thought one could use the native APIs of the
> > > rendering library to handle the transformation
> > > to the desired graphics format (in the spirit
> > > of pngcairo and pdfcairo - both rendered, similarly,
> > > using the same lib). I think Qt can do that, too.
> > 
> > The cairo library can generate PDF, EPS, SVG or PNG at will, but only 
> > given a suitable abstract description of the plot. No library can 
> > transform a graphic from a bitmap format such as PNG to a "proper"
> > vector representation.
> 
> Yes, I realize that. 
> 
> I guess the question then becomes: in what form is
> the graph information is available "when the button 
> is pressed".
> 
> Not knowing the code, I could guess that what is 
> copied to the clipboard (currently) is only the
> already-rendered bitmap. No way to construct a
> meaningful vector graphic from that!
> 
> The implication seems to be that the "save as file"
> GUI event would have to interact more deeply with
> gnuplot's internals: it actually has to go back, get
> the data set (and all that) and recreate the plot,
> basically from scratch, just using a different backend.

That's not the way it works.
The internal representation of the plot gradually built up
by calls into the cairo library is in some I-dont-know-what
vector format. The conversion to a specific output format, 
whether it's bitmap display on the screen or 
pdf for writing into a file, is done on request as the
very last step.

The gnuplot cairo-based terminals all feed the same
commands through to the cairo+pango libraries.
Except for some minor stuff (e.g. font scaling if requested)
they diverge only at that last step.  So having a wxt menu
widget to output to a file ends up generating the
same output you would have gotten if you had chosen
another cairo-based terminal to begin with.
The plot description is already built up and stored.
The button just triggers "convert to pdf" or "convert
to svg" or "redraw on the screen".

	Ethan


> 
> That's different and more complicated than saving an
> already rendered bitmap to the clipboard. I had not 
> appreciated that difficulty sufficiently! (Too bad.)
> 
> > 
> > Consider just fonts, for example: a proper vector file contains the 
> > specification of the fonts used so they can be reproduced at any 
> > resolution. A bitmap contains no real font information, just the
> > pixels that compose the glyphs in the plot at a given, fixed
> > resolution.
> > 
> > Allin Cottrell
> > 
> > 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

-- 
mail:   Biomolecular Structure Center,  K-428 Health Sciences Bldg
        MS 357742,   University of Washington, Seattle 98195-7742