gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Proposal: Saving graphs from Qt and wxt terminals

[Daniel J S. <dan...@ie...>]

On 10/24/2014 05:04 PM, Ethan A Merritt wrote:
> On Friday, 24 October, 2014 15:17:01 Daniel J Sebald wrote:
>> On 10/24/2014 01:18 AM, Philipp K. Janert wrote:
>>>
>>> I'd like to drum up support for a feature that I
>>> don't have the prerequisites to implement myself,
>>> but that might not be very difficult to do for
>>> somebody with the right background.
>>>
>>> I think it would be wonderful if both current
>>> interactive terminals (Qt and wxt) would allow
>>> the user to "save" the current graph to file in
>>> a range of file formats (basically PNG and PDF).
>>>
>>> The way I imagine this would be similar to the
>>> way most (if not all) current GUI applications
>>> handle this action: when the user selects the
>>> corresponding menu entry or presses the button,
>>> a file selection dialog pops up, in which the
>>> user can select/enter the path- and filename
>>> under which to save the graph, and also the
>>> file format. Hit "Ok", and the file is created.
>>
>> I just compiled gnuplot for WXT...  It looks like wxWidgets terminal is
>> quite similar to Qt and it shouldn't be too difficult to make them
>> consistent.  One would need to use the GUI features that come with the
>> library and wxWidgets has a file dialog:
>>
>> http://docs.wxwidgets.org/3.0/classwx_file_dialog.html
>>
>> So that part is easy.  I'd say that perhaps some thought should be put
>> into what the desired layout is though--agreeing on that is probably the
>> difficult part.
>>
>> I consider x11 interactive and a few years ago I wrote a patch to
>> enhance the clipboard for that terminal.  What I recall of X11 is that
>> the format saved to clipboard wasn't really decided until the calling
>> program wanted to paste, at which point the X11 term would provide the
>> suitable format.  Anyway, I had programmed the shortcut keys Cntrl-A to
>> highlight the graph with the typical bluish tint and Cntrl-C to paste to
>> the clipboard.  The point was to make working with the terminal much
>> more fluent.
>>
>> 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?
>>
>> Some other comments:
>>
>> Right now, WXT is not copying anything to clipboard.
>
> Works fine here.  Full color full resolution bitmap is sent to clipboard.
> Ctrl-V in GIMP or soffice  pastes it into an open document or canvas.
>
>> While the Qt
>> terminal copies so that the plot image appears in a WYSIWYG word
>> processor, WXT terminal doesn't create anything.
>
> [shrug] works fine for me.

OK.  WXT Copy/Paste works for GIMP, but not for oowriter.  Qt Copy/Paste 
works for both GIMP and oowriter.  Maybe it is oowriter with an issue; 
I'll investigate a bit.


>> Also the WXT terminal has a fixed aspect ratio where Qt terminal does not.
>
> Again not true here.   The copy/paste is just a bitmap of whatever the
> current display shows.  You can change the aspect ratio to anything
> you like either with "set term wxt size XX,YY"  or by resizing the open
> window with the mouse.

When resizing the window, I'm seeing the plot change size but using the 
maximum size that fits within whatever is the minimum axis that 
maintains aspect ratio.  The rest of the screen is then grey.  I've 
attached a small screenshot.


>> The default pen color is now magenta where for years it was red.  Was
>> that change intentional?
>
> Very much so.
> See, e.g. current lead story on lwn.net
> "Accessibility and the graphics stack" (may not be accessible to
> non-subscribers until next week)
> 	http://lwn.net/Articles/617594/
>
> Or see "help set colors" in version 5rc2 or current cvs.

All right.  I remember the color discussion about a half year back now.

Dan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Philipp K. J. <ja...@ie...>]

[snip]

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

Best,

		Ph.

Re: Proposal: Saving graphs from Qt and wxt terminals

[Philipp K. J. <ja...@ie...>]

[snip]

> > Some other comments:
> > 
> > Right now, WXT is not copying anything to clipboard. 
> 
> Works fine here.  Full color full resolution bitmap is sent to
> clipboard. Ctrl-V in GIMP or soffice  pastes it into an open document
> or canvas.

I can confirm that. It works for me as well,
full-color etc. 

> 
> > While the Qt 
> > terminal copies so that the plot image appears in a WYSIWYG word 
> > processor, WXT terminal doesn't create anything.
> 
> [shrug] works fine for me.

Again, it works for me, but I did notice that
the graph, while on the clipboard, did now show
up in klipper or parcellite - they always showed
"empty clipboard". Since I am not too familiar
with either application, I may not fully understand
what to expect.

> 
> > Also the WXT terminal has a fixed aspect ratio where Qt terminal
> > does not.
> 
> Again not true here.   The copy/paste is just a bitmap of whatever the
> current display shows.  You can change the aspect ratio to anything
> you like either with "set term wxt size XX,YY"  or by resizing the
> open window with the mouse.
> 
> > The default pen color is now magenta where for years it was red.
> > Was that change intentional?
> 
> Very much so. 
> See, e.g. current lead story on lwn.net
> "Accessibility and the graphics stack" (may not be accessible to
> non-subscribers until next week) 
> 	http://lwn.net/Articles/617594/
> 
> Or see "help set colors" in version 5rc2 or current cvs.
> 
> 	Ethan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Ethan A M. <sf...@us...>]

On Friday, 24 October, 2014 15:17:01 Daniel J Sebald 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

Weird.  I get a perfectly normal full-color PDF.

> 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 have been thinking that it would be nice to have build options for
two flavors of gnuplot.

gnuplot+Qt
	no dependence on cairo or wxt
	svg pdf png output via the Qt libraries
	default terminal is qt

gnuplot+wxt
	no dependence on Qt libraries
	pdf png output via cairo  (can it do svg?)
	default terminal is wxt

Either of these options could also do away with dependence on libgd,
so long as people can live without gif/jpeg output.

Given that it looks like wxt3 is causing problems for people who are
building on bleeding edge linux systems (or building on OSX),
the qt-only build option could become important.

	Ethan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Ethan A M. <sf...@us...>]

On Friday, 24 October, 2014 15:17:01 Daniel J Sebald wrote:
> On 10/24/2014 01:18 AM, Philipp K. Janert wrote:
> >
> > I'd like to drum up support for a feature that I
> > don't have the prerequisites to implement myself,
> > but that might not be very difficult to do for
> > somebody with the right background.
> >
> > I think it would be wonderful if both current
> > interactive terminals (Qt and wxt) would allow
> > the user to "save" the current graph to file in
> > a range of file formats (basically PNG and PDF).
> >
> > The way I imagine this would be similar to the
> > way most (if not all) current GUI applications
> > handle this action: when the user selects the
> > corresponding menu entry or presses the button,
> > a file selection dialog pops up, in which the
> > user can select/enter the path- and filename
> > under which to save the graph, and also the
> > file format. Hit "Ok", and the file is created.
> 
> I just compiled gnuplot for WXT...  It looks like wxWidgets terminal is 
> quite similar to Qt and it shouldn't be too difficult to make them 
> consistent.  One would need to use the GUI features that come with the 
> library and wxWidgets has a file dialog:
> 
> http://docs.wxwidgets.org/3.0/classwx_file_dialog.html
> 
> So that part is easy.  I'd say that perhaps some thought should be put 
> into what the desired layout is though--agreeing on that is probably the 
> difficult part.
> 
> I consider x11 interactive and a few years ago I wrote a patch to 
> enhance the clipboard for that terminal.  What I recall of X11 is that 
> the format saved to clipboard wasn't really decided until the calling 
> program wanted to paste, at which point the X11 term would provide the 
> suitable format.  Anyway, I had programmed the shortcut keys Cntrl-A to 
> highlight the graph with the typical bluish tint and Cntrl-C to paste to 
> the clipboard.  The point was to make working with the terminal much 
> more fluent.
> 
> 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?
> 
> Some other comments:
> 
> Right now, WXT is not copying anything to clipboard. 

Works fine here.  Full color full resolution bitmap is sent to clipboard.
Ctrl-V in GIMP or soffice  pastes it into an open document or canvas.

> While the Qt 
> terminal copies so that the plot image appears in a WYSIWYG word 
> processor, WXT terminal doesn't create anything.

[shrug] works fine for me.

> Also the WXT terminal has a fixed aspect ratio where Qt terminal does not.

Again not true here.   The copy/paste is just a bitmap of whatever the
current display shows.  You can change the aspect ratio to anything
you like either with "set term wxt size XX,YY"  or by resizing the open
window with the mouse.

> The default pen color is now magenta where for years it was red.  Was 
> that change intentional?

Very much so. 
See, e.g. current lead story on lwn.net
"Accessibility and the graphics stack" (may not be accessible to
non-subscribers until next week) 
	http://lwn.net/Articles/617594/

Or see "help set colors" in version 5rc2 or current cvs.

	Ethan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Daniel J S. <dan...@ie...>]

On 10/24/2014 01:18 AM, Philipp K. Janert wrote:
>
> I'd like to drum up support for a feature that I
> don't have the prerequisites to implement myself,
> but that might not be very difficult to do for
> somebody with the right background.
>
> I think it would be wonderful if both current
> interactive terminals (Qt and wxt) would allow
> the user to "save" the current graph to file in
> a range of file formats (basically PNG and PDF).
>
> The way I imagine this would be similar to the
> way most (if not all) current GUI applications
> handle this action: when the user selects the
> corresponding menu entry or presses the button,
> a file selection dialog pops up, in which the
> user can select/enter the path- and filename
> under which to save the graph, and also the
> file format. Hit "Ok", and the file is created.

I just compiled gnuplot for WXT...  It looks like wxWidgets terminal is 
quite similar to Qt and it shouldn't be too difficult to make them 
consistent.  One would need to use the GUI features that come with the 
library and wxWidgets has a file dialog:

http://docs.wxwidgets.org/3.0/classwx_file_dialog.html

So that part is easy.  I'd say that perhaps some thought should be put 
into what the desired layout is though--agreeing on that is probably the 
difficult part.

I consider x11 interactive and a few years ago I wrote a patch to 
enhance the clipboard for that terminal.  What I recall of X11 is that 
the format saved to clipboard wasn't really decided until the calling 
program wanted to paste, at which point the X11 term would provide the 
suitable format.  Anyway, I had programmed the shortcut keys Cntrl-A to 
highlight the graph with the typical bluish tint and Cntrl-C to paste to 
the clipboard.  The point was to make working with the terminal much 
more fluent.

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?

Some other comments:

Right now, WXT is not copying anything to clipboard.  While the Qt 
terminal copies so that the plot image appears in a WYSIWYG word 
processor, WXT terminal doesn't create anything.

Also the WXT terminal has a fixed aspect ratio where Qt terminal does not.

The aspect ratio for WXT (and PDF terminal output) seems much more 
wide/flat than it used to.

The default pen color is now magenta where for years it was red.  Was 
that change intentional?

Dan

Re: Proposal: Saving graphs from Qt and wxt terminals

[<pl...@pi...>]

On 10/24/14 17:45, Allin Cottrell wrote:
>
> On Fri, 24 Oct 2014, pl...@pi... wrote:
>
> [...]
>> I don't see any sense in saving  a graphic as PDF. Maybe someone could
>> say why people do this. AFAIK it justs adds a wrapper around the image
>> and bloats it.
>
> Not at all. People save plots as PDF because they want them to be
> scalable without horrid pixelation, and to exploit the full resolution
> of the final output device (e.g. a 2400 dpi printer). For this purpose
> you want a vector format -- PDF, EPS or SVG -- not a bitmap.
>
> Allin Cottrell
>

Thanks,  that is the point of pdf terminal. I make quite a bit of use of 
SVG myself.  I do not think this makes sense for clipboard copy of 
interactive terminals.which is necessarily a bitmap.

Peter.

Re: Proposal: Saving graphs from Qt and wxt terminals

[Ethan A M. <sf...@us...>]

On Friday, 24 October, 2014 09:10:51 Petr Mikulik wrote:
> > I think it would be wonderful if both current
> > interactive terminals (Qt and wxt) would allow
> > the user to "save" the current graph to file in
> > a range of file formats (basically PNG and PDF).
> 
> This reminds me: there is an undocumented command for printing
> the current graph (i.e. for showing a Print(er) dialog):
>  	screendump
> This, however, works for the "windows" terminal only, otherwise
> gnuplot says
>  	screendump not implemented
> 
> Currently:
> - Windows terminal has icons to:
>  	- print the graph
>  	- save it as EMF
> - OS/2 pm terminal has menu item for:
>  	- print the graph
> - Qt has a tiny arrow with a menu for:
>  	- print the graph
>  	- export the graph to png, svg, image
> 
> Some ideas:
> - The screendump command could work for Qt as well.

How would this be different from the existing qt->png output?

> - This command should be documented.
> - Cannot wxt have the same export/print icons as Qt?

The Qt library provides conversion routines for png, pdf, and svg.

I am not so familiar with the wxt library, but so far as I can see from the
available routines the closest equivalent would end up doing exactly the
same thing as "set term pngcairo; replot" for png output.
Same for pdf ouput.
We don't have a svgcairo terminal, however.

> - Generalize it as "screendump <terminal name>"?

Wouldn't that be "screendump 'filename'"?

	Ethan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Philipp K. J. <ja...@ie...>]

On Fri, 24 Oct 2014 08:55:49 +0200
Bastian Märkisch <bma...@we...> wrote:

> Am 24.10.2014 um 08:18 schrieb Philipp K. Janert:
> >
> > I'd like to drum up support for a feature that I
> > don't have the prerequisites to implement myself,
> > but that might not be very difficult to do for
> > somebody with the right background.
> >
> > I think it would be wonderful if both current
> > interactive terminals (Qt and wxt) would allow
> > the user to "save" the current graph to file in
> > a range of file formats (basically PNG and PDF).
> >
> 
> FYIW, the qt terminal does already have that feature (at least in 
> version 5), but misses a scripting possibility. This is addressed by 
> patch #665:
> https://sourceforge.net/p/gnuplot/patches/665/
> 

Thanks for the reminder; I need to check this out
again. (Qt does not work for me (see previous
string on this list!), so I need to find another
installation to take a look.)

>    Bastian

Re: Proposal: Saving graphs from Qt and wxt terminals

[Allin C. <cot...@wf...>]

On Fri, 24 Oct 2014, pl...@pi... wrote:

[...]
> I don't see any sense in saving  a graphic as PDF. Maybe someone could
> say why people do this. AFAIK it justs adds a wrapper around the image
> and bloats it.

Not at all. People save plots as PDF because they want them to be scalable 
without horrid pixelation, and to exploit the full resolution of the final 
output device (e.g. a 2400 dpi printer). For this purpose you want a 
vector format -- PDF, EPS or SVG -- not a bitmap.

Allin Cottrell

Re: Proposal: Saving graphs from Qt and wxt terminals

[Philipp K. J. <ja...@ie...>]

[snip]

> This need arises because the current output of , say the png
> terminal, looks very different from the interactive version of graph.
> I long since gave up trying to tune the two to be sufficiently
> similar and use the clipboard function.

That was actually not the reason for my suggestion
at all. I am not trying to solve the problem that
graphs made by the gd-lib png terminal look different
from the ones made by the wxt terminal.

My motivation is "ease of use", in a GUI-spirit:
click the "save" button, and gnuplot does what
every other GUI application does when you hit 
the "save" button. Namely, offer a file dialog,
and save to file.

> 
> One quick way to do this, which could be a first step without all the 
> dialogues would be to add a termopt :
> eg.
> termopt saveDir="/tmp/gnuplot" saveFormat="png"

Yes, I agree, I have toyed with the idea of adding
a command, let's call it "export" (to distinguish it
from "save", which saves commands) that would accept
a terminal type and a filename as arguments and do
all of the required steps (including reinstating the
interactive terminal to its previous settings), like so:

export "graph.png" pngcairo 

One could even supply addtl options, and pass them on
to the selected terminal. As you said, I'd be capable
of putting that together, and maybe I will (one day).

[snip]

> 
> This would be most useful to me. I don't want to have to go through a 
> metric tonne of option dialogues like gimp does or do battle with the 
> standard file dialogues that require a lot of clicking if you want to
> go anywhere other "my documents".

Keep in mind that I am not necessarily thinking of
the power-user in power-mode. I am thinking of the
occasional user, or a power-user who "just wants to
save this graph". Different use case, equally valid.

> 
> What would be nice in gnuplot is a one line configuration command 
> entered from a console that allows a one click save afterwards. A
> simple text entry for file name is all that is needed. Default to
> last used name to overwrite or change.

[snip]
 
> If I had to do something like one console command :
> termopt saveDir="/tmp/gnuplot" saveFormat="png" saveFile="test.png"
> 
> then a single click interaction on the interactive terminal this
> would be significant  time saver for me and would provide a
> satisfactory minimalistic  solution.

That's still a two-step process. Why not roll it all into
one? 

In any case, I think having such functionality would be
goodness. Nevertheless, I think it would make sense to
also have a proper, GUI-style way of saving a graph - 
in particular since we are already 3/4 of the way there
(with the clipboard feature).

Re: Proposal: Saving graphs from Qt and wxt terminals

[Philipp K. J. <ja...@ie...>]

On Fri, 24 Oct 2014 08:58:31 -0700
sfeam <sf...@us...> wrote:

> On Friday, 24 October 2014 10:24:50 AM pl...@pi... wrote:
> 
> > In principal I agree that there is a need here. Firing up another 
> > program just to use its saveAs dialogue seems suboptimal.
> 
> It's quite painless in practice.  Try this:

Well, it appears painless because we gnuplot users
have been used to jumping through these hoops
for the last 25 years! Try explaining it to 
someone NEW to gnuplot and then watch their
reaction. Would we really design it the way it
is, if we starting over today?

I want to make sure my motivation is understood:
obviously, graphs can be saved from gnuplot. But
the way it's done is unnecessarily cumbersome and
not in line with current-day expectations.

I also don't suggest to replace the standard,
command-based process. 

Instead, my suggestion really boils down to this:
given that there already is the "copy-to-clipboard"
function, can we extend it and have it copy to a
file, instead of the clipboard? 

> 
> set term png
> set output "|display png:-"
> plot $whatever
> 
> # plot will appear on your screen.
> # if you like it and want to save it, then
> 
> set output 'itsakeeper.png'
> replot
> 
> 
> I use the "display" command from ImageMagick, but if you prefer some
> other viewer you can substitute the display command as appropriate.
> 
> 	Ethan
> 
> 

Re: Proposal: Saving graphs from Qt and wxt terminals

[Philipp K. J. <ja...@ie...>]

[snip]

> 
> I don't see any sense in saving  a graphic as PDF. Maybe someone
> could say why people do this. AFAIK it justs adds a wrapper around
> the image and bloats it.
> 
> I can't think what situations would be able to display a PDF that
> cannot display a png directly.
> 

Because PDF is a vector format, in the same
way that Postscript is! Whenever there is a
need to scale a graph, you need a vector format.

Postscript is (increasingly) becoming a niche 
format, and PDF is taking its place as print-quality
vector format.

Re: Proposal: Saving graphs from Qt and wxt terminals

[sfeam <sf...@us...>]

On Friday, 24 October 2014 10:24:50 AM pl...@pi... wrote:

> In principal I agree that there is a need here. Firing up another 
> program just to use its saveAs dialogue seems suboptimal.

It's quite painless in practice.  Try this:

set term png
set output "|display png:-"
plot $whatever

# plot will appear on your screen.
# if you like it and want to save it, then

set output 'itsakeeper.png'
replot


I use the "display" command from ImageMagick, but if you prefer some
other viewer you can substitute the display command as appropriate.

	Ethan



> This need arises because the current output of , say the png terminal, 
> looks very different from the interactive version of graph. I long since 
> gave up trying to tune the two to be sufficiently similar and use the 
> clipboard function.
> 
> One quick way to do this, which could be a first step without all the 
> dialogues would be to add a termopt :
> eg.
> termopt saveDir="/tmp/gnuplot" saveFormat="png"
> 
> Default could be `pwd` . I usually save my plots in the same directory 
> that the data I'm working on is in.
> 
> This could then be done with a single click from the interface, with 
> some default compression parameters for png.
> 
> This would be most useful to me. I don't want to have to go through a 
> metric tonne of option dialogues like gimp does or do battle with the 
> standard file dialogues that require a lot of clicking if you want to go 
> anywhere other "my documents".
> 
> The gimp solution is full of options if you want to tune everything and 
> has full saveAs ( sorry that's called 'export' now :? ) capability.
> 
> What would be nice in gnuplot is a one line configuration command 
> entered from a console that allows a one click save afterwards. A simple 
> text entry for file name is all that is needed. Default to last used 
> name to overwrite or change.
> 
> I agree that both the wx and qt libs would require a steep learning 
> curve for someone not familiar with them.
> 
> The simplest way would be to also specify the file name in termopts. 
> This would make getting the nuts and bolts of a mechanism in place 
> relatively simple.
> 
> 
> 
> If I had to do something like one console command :
> termopt saveDir="/tmp/gnuplot" saveFormat="png" saveFile="test.png"
> 
> then a single click interaction on the interactive terminal this would 
> be significant  time saver for me and would provide a satisfactory 
> minimalistic  solution.
> 
> Error conditions could be reported directly to the console.
> 
> Maybe this is something Philipp could achieve without spending weeks in 
> the bowels of library code.
> 
> 
> 
> I don't see any sense in saving  a graphic as PDF. Maybe someone could 
> say why people do this. AFAIK it justs adds a wrapper around the image 
> and bloats it.
> 
> I can't think what situations would be able to display a PDF that cannot 
> display a png directly.
> 
> 
> Regards. Peter.
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Proposal: Saving graphs from Qt and wxt terminals

[<pl...@pi...>]

On 10/24/14 08:18, Philipp K. Janert wrote:
>
>
> I'd like to drum up support for a feature that I
> don't have the prerequisites to implement myself,
> but that might not be very difficult to do for
> somebody with the right background.
>
> I think it would be wonderful if both current
> interactive terminals (Qt and wxt) would allow
> the user to "save" the current graph to file in
> a range of file formats (basically PNG and PDF).
>
> The way I imagine this would be similar to the
> way most (if not all) current GUI applications
> handle this action: when the user selects the
> corresponding menu entry or presses the button,
> a file selection dialog pops up, in which the
> user can select/enter the path- and filename
> under which to save the graph, and also the
> file format. Hit "Ok", and the file is created.
>
> The current "copy to clipboard" function goes
> a long way in this direction, but is not perfect.
> It introduces a dependency on the clipboard and
> how it works (under different window managers),
> and may require the user to start another application.
> (For instance, I can "paste" from the clipboard
> into the Gimp, but I have not found a way to save
> directly from clipboard to file - which is what
> I really need.)
>
> "Saving a graph" from gnuplot has always been awkward,
> and of course there are good and venerable historical
> reasons for that. But with the Cairo/wxt/Qt-based
> terminals, we are in a position to make this process
> so much better - the "copy-to-clipboard" feature
> shows what it could be like! All I am suggesting
> is an additional dialog that let's the user choose
> a filename. I think that would bring gnuplot's behavior
> much closer to what users are expecting, given their
> experience with other GUI applications.
>
> (The classic, text-based process would continue
> to exist, unchanged, for scripting purposes and
> fine-grained control.)
>
> But: I can't do it myself. I have never programmed
> wxt (and Qt most recently almost 10 years ago) and I
> am not going to figure out how to enter this functionality
> into gnuplot. (I did take a look at wxt_gui.cpp and
> realized quickly that this is beyond me.) But for
> someone who knows these libraries, this might not be
> that difficult a task: both libs provide complete
> widgets for file selection dialog (wxFileDialog and
> QFileDialog, resp). Would it be very difficult to
> hook them up in the right places?
>
> I think it would make a world of a difference to
> people - and do much to dispell the myth that
> gnuplot is "hard to learn".
>
> Best,
>
> 		Ph.
>

In principal I agree that there is a need here. Firing up another 
program just to use its saveAs dialogue seems suboptimal.

This need arises because the current output of , say the png terminal, 
looks very different from the interactive version of graph. I long since 
gave up trying to tune the two to be sufficiently similar and use the 
clipboard function.

One quick way to do this, which could be a first step without all the 
dialogues would be to add a termopt :
eg.
termopt saveDir="/tmp/gnuplot" saveFormat="png"

Default could be `pwd` . I usually save my plots in the same directory 
that the data I'm working on is in.

This could then be done with a single click from the interface, with 
some default compression parameters for png.

This would be most useful to me. I don't want to have to go through a 
metric tonne of option dialogues like gimp does or do battle with the 
standard file dialogues that require a lot of clicking if you want to go 
anywhere other "my documents".

The gimp solution is full of options if you want to tune everything and 
has full saveAs ( sorry that's called 'export' now :? ) capability.

What would be nice in gnuplot is a one line configuration command 
entered from a console that allows a one click save afterwards. A simple 
text entry for file name is all that is needed. Default to last used 
name to overwrite or change.

I agree that both the wx and qt libs would require a steep learning 
curve for someone not familiar with them.

The simplest way would be to also specify the file name in termopts. 
This would make getting the nuts and bolts of a mechanism in place 
relatively simple.



If I had to do something like one console command :
termopt saveDir="/tmp/gnuplot" saveFormat="png" saveFile="test.png"

then a single click interaction on the interactive terminal this would 
be significant  time saver for me and would provide a satisfactory 
minimalistic  solution.

Error conditions could be reported directly to the console.

Maybe this is something Philipp could achieve without spending weeks in 
the bowels of library code.



I don't see any sense in saving  a graphic as PDF. Maybe someone could 
say why people do this. AFAIK it justs adds a wrapper around the image 
and bloats it.

I can't think what situations would be able to display a PDF that cannot 
display a png directly.


Regards. Peter.

Re: Proposal: Saving graphs from Qt and wxt terminals

[Petr M. <mi...@ph...>]

> I think it would be wonderful if both current
> interactive terminals (Qt and wxt) would allow
> the user to "save" the current graph to file in
> a range of file formats (basically PNG and PDF).

This reminds me: there is an undocumented command for printing
the current graph (i.e. for showing a Print(er) dialog):
 	screendump
This, however, works for the "windows" terminal only, otherwise
gnuplot says
 	screendump not implemented

Currently:
- Windows terminal has icons to:
 	- print the graph
 	- save it as EMF
- OS/2 pm terminal has menu item for:
 	- print the graph
- Qt has a tiny arrow with a menu for:
 	- print the graph
 	- export the graph to png, svg, image

Some ideas:
- The screendump command could work for Qt as well.
- This command should be documented.
- Cannot wxt have the same export/print icons as Qt?
- Generalize it as "screendump <terminal name>"?

---
PM

Re: Proposal: Saving graphs from Qt and wxt terminals

[Bastian M. <bma...@we...>]

Am 24.10.2014 um 08:18 schrieb Philipp K. Janert:
>
> I'd like to drum up support for a feature that I
> don't have the prerequisites to implement myself,
> but that might not be very difficult to do for
> somebody with the right background.
>
> I think it would be wonderful if both current
> interactive terminals (Qt and wxt) would allow
> the user to "save" the current graph to file in
> a range of file formats (basically PNG and PDF).
>

FYIW, the qt terminal does already have that feature (at least in 
version 5), but misses a scripting possibility. This is addressed by 
patch #665:
https://sourceforge.net/p/gnuplot/patches/665/

   Bastian

Proposal: Saving graphs from Qt and wxt terminals

[Philipp K. J. <ja...@ie...>]

I'd like to drum up support for a feature that I
don't have the prerequisites to implement myself,
but that might not be very difficult to do for 
somebody with the right background.

I think it would be wonderful if both current
interactive terminals (Qt and wxt) would allow 
the user to "save" the current graph to file in 
a range of file formats (basically PNG and PDF).

The way I imagine this would be similar to the
way most (if not all) current GUI applications
handle this action: when the user selects the
corresponding menu entry or presses the button,
a file selection dialog pops up, in which the 
user can select/enter the path- and filename 
under which to save the graph, and also the 
file format. Hit "Ok", and the file is created.

The current "copy to clipboard" function goes
a long way in this direction, but is not perfect.
It introduces a dependency on the clipboard and
how it works (under different window managers),
and may require the user to start another application.
(For instance, I can "paste" from the clipboard 
into the Gimp, but I have not found a way to save
directly from clipboard to file - which is what
I really need.)

"Saving a graph" from gnuplot has always been awkward,
and of course there are good and venerable historical 
reasons for that. But with the Cairo/wxt/Qt-based
terminals, we are in a position to make this process
so much better - the "copy-to-clipboard" feature 
shows what it could be like! All I am suggesting
is an additional dialog that let's the user choose
a filename. I think that would bring gnuplot's behavior 
much closer to what users are expecting, given their 
experience with other GUI applications.

(The classic, text-based process would continue 
to exist, unchanged, for scripting purposes and 
fine-grained control.)

But: I can't do it myself. I have never programmed
wxt (and Qt most recently almost 10 years ago) and I 
am not going to figure out how to enter this functionality 
into gnuplot. (I did take a look at wxt_gui.cpp and 
realized quickly that this is beyond me.) But for 
someone who knows these libraries, this might not be
that difficult a task: both libs provide complete
widgets for file selection dialog (wxFileDialog and
QFileDialog, resp). Would it be very difficult to 
hook them up in the right places? 

I think it would make a world of a difference to
people - and do much to dispell the myth that 
gnuplot is "hard to learn". 

Best,

		Ph.

Re: change handling of time data for 5.0?

[Ethan A M. <sf...@us...>]

On Monday, 06 October, 2014 18:33:42 Karl Ratzsch wrote:
> Am 06.10.2014 um 17:01 schrieb sfeam:
> > On Monday, 06 October 2014 12:53:07 PM Karl Ratzsch wrote:
> > 
> >> Wasn´t the idea to deprecate "set xdata time" because it always
> >> changes the ticslabel format type? I don´t see how it is still
> >> necessary now, except for backward compatibility, of course.
> > 
> > 
> > I'm not following you here. If we deprecated "set xdata time",
> > wouldn't we just have to introduce another command that did the
> > same thing? What would be the point?
> 
> There is no need for a replacement, i think. timecolumn() and strptime()
> can handle all timedata input. Plus "_data time" is limited to certain
> columns, depending on the plot style, and it is limited to one format.
> 
> So in many cases, people cannot use "_data time" anyway. 

I think everyone agrees on that specific point.  That was why
timecolumn() got a 2nd parameter, even before this recent round of revision.

> For the sake of a uniform UI, i´d say don´t use it at all.

But there we run head-on into the policy for backward compatibility
if possible.  Yes you can now write scripts that do not use "set xdata".
But that by itself doesn't justify breaking old scripts that do use it.
And getting back to your other example, it's still convenient to say
   set xdata time
   set timefmt "%d-%b"
   set arrow 1 from "01-Jan", y0  to  "05-Sep",y0+ydel
rather than
   timefmt = "%d-%b"
   set arrow 1 from strptime(timefmt,"01-Jan"),y0 \
                           to strptime(timefmt,"05-Sep"),y0+ydel

> > The thing that we might want to change is that "set xdata time"
> > might stop _also_ affecting 'set xtics time'. That would make the
> > input/output separation more complete, but would not be backwards
> > compatible.
> 
> Ah. We´ve been talking under different presumptions. ;-)
> Here´s mine:
> 
> It´s rather impossible to really separate in/output with "set xdata
> time", because it´s nomenclature says "plot abscissa" when it really
> means "first input column".

The more important point is that it means "use timefmt specifiers
rather than normal C numeric format specifiers".  Without this flag,
the gnuplot parsing routines don't know which library routine to 
feed the format statement to.  That functionality is not tied to any
particular input column or file, since it is also relevant to position info
and in particular to axis ranges.   I think of "set xdata" as being
parallel in syntax to "set xrange". 

> As this can´t be fixed, i say keep it for backward compatibility, but rebuild
> the functionality otherwise.

Exactly.
But "keep it for backward compatibility" is opposite to "deprecate it",
right?

> One small thing is still missing, imho: "set arrow" et al. should check
> if coordinates are set to time mode with "set _tics" (as it checks for
> "xdata time" now), and use the format set via "set timefmt" in that
> case. (not the one used to format the tic labels.)

I'm confused.  I thought we agreed in a separate Email thread that
positional coordinates, including arrows, should continue to be considered
'input' (using xdata/timefmt) rather than 'output' (using xtics/format)?

Under the new scheme it would never be correct to mix these up,
using axis->tictype  (internal flag for "set xtics") to control use of timefmt,
which is controlled instead by axis->datatype (internal flag for "set xdata").

> Additional features are possible, of course:
> One could for example introduce something like "set data <colnum>
> {time|date|..} {format}" so people don´t have to use the lenghty
> timecolumn() function every time.

Sure, but let's leave that for later.  It would be a purely new feature,
so it  doesn't affect current discussions of compatibility or
syntax change.

	Ethan

Re: change handling of time data for 5.0?

[Karl R. <ra...@un...>]

Am 06.10.2014 um 17:01 schrieb sfeam:
> On Monday, 06 October 2014 12:53:07 PM Karl Ratzsch wrote:
> 
>> Wasn´t the idea to deprecate "set xdata time" because it always
>> changes the ticslabel format type? I don´t see how it is still
>> necessary now, except for backward compatibility, of course.
> 
> 
> I'm not following you here. If we deprecated "set xdata time",
> wouldn't we just have to introduce another command that did the
> same thing? What would be the point?

There is no need for a replacement, i think. timecolumn() and strptime()
can handle all timedata input. Plus "_data time" is limited to certain
columns, depending on the plot style, and it is limited to one format.

So in many cases, people cannot use "_data time" anyway. For the sake of
a uniform UI, i´d say don´t use it at all.

> The thing that we might want to change is that "set xdata time"
> might stop _also_ affecting 'set xtics time'. That would make the
> input/output separation more complete, but would not be backwards
> compatible.

Ah. We´ve been talking under different presumptions. ;-)
Here´s mine:

It´s rather impossible to really separate in/output with "set xdata
time", because it´s nomenclature says "plot abscissa" when it really
means "first input column". As this can´t be fixed, i say keep it for
backward compatibility, but rebuild the functionality otherwise.

The functionality we already have now, with timecolumn(), strptime() and
"set _tics time", so i thought the change ought to be made now, with 5.0
at the door.

One small thing is still missing, imho: "set arrow" et al. should check
if coordinates are set to time mode with "set _tics" (as it checks for
"xdata time" now), and use the format set via "set timefmt" in that
case. (not the one used to format the tic labels.)

Additional features are possible, of course:

One could for example introduce something like "set data <colnum>
{time|date|..} {format}" so people don´t have to use the lenghty
timecolumn() function every time.


What´d you think?

  Best, Karl



-- 
Karl-Friedrich Ratzsch (Dipl. Chem.)
Freiburger Materialforschungszentrum / Universität Freiburg
Stefan-Meier-Straße 21, 79104 Freiburg im Breisgau
Tel. 0761/203-4748 Fax:-4701
ra...@un...

Re: change handling of time data for 5.0?

[sfeam <sf...@us...>]

On Sunday, 05 October 2014 05:22:22 PM Karl Ratzsch wrote:
> Am 05.10.2014 15:27, schrieb Karl Ratzsch:
> > i just checked out the latest 5.1 cvs, and it seems to work just nicely.
> > 
> 
> One more :
> 
> Coordinates given for e.g. "set arrow" still need "xdata time":
> 
>  set timefmt "%H:%M:%S"
>  set arrow 1 from "12:31:01.4",10 to "12:31:01.7",35

Yes, because all positional coordinates are treated as "input"
rather than "output".   So axis ranges, objects, labels, etc
all use xdata+timefmt rather than xtics+format.

That's the way it has always been.  I don't see a strong argument
for changing it.  No matter what you choose it's going to be at
least a bit confusing.  And really it does make sense.  That's 
the format the time coordinates would require if the vector
endpoints were being plotted from a data file.  Shouldn't the
coordinate format be the same regardless of whether the endpoints
come from a file or from the command line?

> This is alright for backward compatibility, however the new syntax
> cannot decide if a string is just a numeral stored as a string variable
> or a timestring that needs to be interpreted according to the format
> string set by "set timefmt".

??
I'm not following you there.
I thought that the behavior has always been, and continues to be,
that a bare number was treated as numerical seconds while a 
string was fed through strptime.

A numeral stored as a string also works, so long as timefmt
contains "%s".

I might have broken this for some particular case, but I did test
it for labels and axis ranges.  Do you have an example of breakage?

> To resolve this, i propose to give the function strptime() a default
> format e.g. -1 which refers to the momentary "set timefmt" setting.
> 
>  set arrow 1 from strptime(-1,"12:31:01.4"),10 \
> 		to strptime(-1,"12:31:01.7"),35
> 
> For actual use, the doc can then suggest defining a function
> 
>  TSx(timestr) = strptime(-1,timestr)
> 
> to save typing.

Might as well just do the save for strptime as I did for timecolumn,
change it internally to accept a variable number of parameters.
1 parameter means "use default timefmt". 2 parameters means "use the
time format in parameter 1".

But I don't think this is needed.
 
> P.S. Should there be a threat about a possible future removal of "set
> xdata time" in the docs? Perhaps not. The underlying input/output
> problem should be resolved, and for people who plot a lot of time scales
> it is just quite convenient.

"set xdata time" is still needed in order to control input data parsing.
The recent changes only affect how the tic labels and mouse coord readout
are handled on output.  The input processing remains the same as before
unless I inadvertently broke something.

	Ethan

Re: change handling of time data for 5.0?

[sfeam <sf...@us...>]

On Sunday, 05 October 2014 03:27:34 PM Karl Ratzsch wrote:
> i just checked out the latest 5.1 cvs, and it seems to work just nicely.
> 
> Am 04.10.2014 21:00, schrieb sfeam:
> > plot <foo> using (Offset_2_weeks + timecolumn(N)):M
> > 
> > I don't see a way to catch that without adding additional bookkeeping

After making the large set of changes I went back and modified the 
parsing to handle "timecolumn" as a special case with a variable
number of parameters.  So this caveat no longer applies.

> 
> - Changing back to "set xtics numeric" keeps a previously set time
> formatstring, which then throws an error "Bad format character". 

The analogous problem was present before this change also:
version 4:

   set xdata time
   set format x "%b-%Y"
   plot [0:1e8]	# All fine
   unset xdata
   replot       # Bad format character

The only difference is that now you can trigger the same thing
with "set xtics".

> I think
> the different output format strings should be kept in separate
> variables, with default values for each. (Dang, that would break
> backward compatibility to some extent, depending on the order of
> commands. Perhaps store them in additional variables, and copy them to
> the actually used tics format variable whenever an "(un)set xdata time"
> or "set xtics time/numeric/.." command is issued. "set xtics format
> <fstring>" would only change the latter, then.)

That's what the version 4 code was doing (although it was not
documented). But it didn't avoid the problem above.
Maybe we can come up with a clever improvement.

> - The synonymous "set format x/y/x2/.. <formatstring>" command also
> needs the time/numeric/.. option.

I was thinking that putting the keyword there was an
alternative to putting in "set xtics".  But maybe you are
right that it should be allowed in either place. 
If you don't give any keyword at all in such a command,
would it reset to "numeric" or would it leave the current
setting unchanged?   I can see advantages either way.

Re: change handling of time data for 5.0?

[Karl R. <ra...@un...>]

Am 05.10.2014 15:27, schrieb Karl Ratzsch:
> i just checked out the latest 5.1 cvs, and it seems to work just nicely.
> 

One more :

Coordinates given for e.g. "set arrow" still need "xdata time":

 set timefmt "%H:%M:%S"
 set arrow 1 from "12:31:01.4",10 to "12:31:01.7",35

This is alright for backward compatibility, however the new syntax
cannot decide if a string is just a numeral stored as a string variable
or a timestring that needs to be interpreted according to the format
string set by "set timefmt".

To resolve this, i propose to give the function strptime() a default
format e.g. -1 which refers to the momentary "set timefmt" setting.

 set arrow 1 from strptime(-1,"12:31:01.4"),10 \
		to strptime(-1,"12:31:01.7"),35

For actual use, the doc can then suggest defining a function

 TSx(timestr) = strptime(-1,timestr)

to save typing.

   Karl


P.S. Should there be a threat about a possible future removal of "set
xdata time" in the docs? Perhaps not. The underlying input/output
problem should be resolved, and for people who plot a lot of time scales
it is just quite convenient.

P.P.S. I noticed this while working on gnuplot.doc but will stop now
until this is decided.

Re: change handling of time data for 5.0?

[Karl R. <ra...@un...>]

i just checked out the latest 5.1 cvs, and it seems to work just nicely.

Am 04.10.2014 21:00, schrieb sfeam:
> plot <foo> using (Offset_2_weeks + timecolumn(N)):M
> 
> I don't see a way to catch that without adding additional bookkeeping

Also no problem here, if the "timefmt" is set, so there seems to be full
compatibility to the (documented part of) v4 behaviour.

I noticed two minor glitches:

- Changing back to "set xtics numeric" keeps a previously set time
formatstring, which then throws an error "Bad format character". I think
the different output format strings should be kept in separate
variables, with default values for each. (Dang, that would break
backward compatibility to some extent, depending on the order of
commands. Perhaps store them in additional variables, and copy them to
the actually used tics format variable whenever an "(un)set xdata time"
or "set xtics time/numeric/.." command is issued. "set xtics format
<fstring>" would only change the latter, then.)

- The synonymous "set format x/y/x2/.. <formatstring>" command also
needs the time/numeric/.. option.

  Karl



-- 
Karl-Friedrich Ratzsch (Dipl. Chem.)
Freiburger Materialforschungszentrum / Universität Freiburg
Stefan-Meier-Straße 21, 79104 Freiburg im Breisgau
Tel. 0761/203-4748 Fax:-4701
ra...@un...

Re: change handling of time data for 5.0?

[sfeam <sf...@us...>]

I have made a set of changes in 5.1 CVS related to timefmt.
These changes are not yet in 5.0, but unless they produce unforseen
problems I expect they will be added before the final release of 5.0.

The changes can be summarized briefly.

- The per-axis flag for how to interpret input/output format statements
  has been split into two separate flags
  axis->datatype  continues to select between numeric or time data on input
  axis->tictype (new) specifies how the axis tics are to be handled (output)

- The new flag is set/unset by a corresponding new command option
  set xtics {numeric|time|geographic}

  For now the command "set xdata time" implicitly also does "set xtics time"
  so all old scripts should continue to act as they did previously with 
  regard to time formats

- The per-axis string axis->timefmt has been replaced by a single global
  timefmt string.  This is what the documentation always described,
  although it was not true in the code.
  
  Existing scripts will only see a change if they used the undocumented
  command:   set timefmt y 'something-different-from-x'.
  This case is handled more flexibly in version 5 by 
     plot ... using (timecolumn(N,format1)):(timecolumn(M,format2))

- XYZ positions are printed using time/date formatting if it is active.
  This makes the output consistent with input requirements.
  I.e. the sequence of commands
     set xdata time
     set label "FOO" at "01/02/14,11:23", graph 0.5
     save 'temp'
     load 'temp'
     show label
  Did not act as you would expect in version 4. Now it does.

- The timecolumn(N,format) command tries to detect being called
  with only 1 parameter, as was the case in version 4.  In this
  case the version 5 code now emulates version 4 behavior, so this
  is an improvement, albeit imperfect, in backwards-compatibility.

In short these changes are intended to both extend the flexibility
of time format handling in version 5 and increase the backwards
compatibility with scripts written for version 4.  Please report
any use cases where these goals not succeeded.

	Ethan