Menu
▾
▴
gnuplot-beta
|
From: Philipp K. J. <ja...@ie...> - 2014-10-24 23:20:36
|
[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. |
|
From: Petr M. <mi...@ph...> - 2014-10-25 21:15:03
|
> I guess the question then becomes: in what form is > the graph information is available "when the button > is pressed". And unfortunately plots via "set multiplot" would fail completely as this command set-up is not available at all. --- PM |
|
From: sfeam <sf...@us...> - 2014-10-25 22:05:06
|
On Saturday, 25 October 2014 11:14:52 PM Petr Mikulik wrote: > > I guess the question then becomes: in what form is > > the graph information is available "when the button > > is pressed". > > And unfortunately plots via "set multiplot" would fail completely as this > command set-up is not available at all. That's not true. If you use the save menu widget from the Qt terminal it will save the entire multiplot. try it and see, Ethan |
|
From: Daniel J S. <dan...@ie...> - 2014-10-25 21:57:02
|
On 10/25/2014 04:14 PM, Petr Mikulik wrote: >> I guess the question then becomes: in what form is >> the graph information is available "when the button >> is pressed". > > And unfortunately plots via "set multiplot" would fail completely as this > command set-up is not available at all. Oh yeah, I forgot about the multiplot limitation. That does suggest the best way to go is to use custom "save as PDF", etc. for each terminal, at least until a more whole-page-like organization for the core comes along. So, everyone, what is the preferred layout for the window? Is it like Qt terminal currently is? Would you prefer a single menu button for "copy to clipboard" (like wxt) with an additional menu button for saving to a file? For me, I like the copy/paste operations to be very fluent. Saving to file I can have be a little less fluent. I generally like drop down menus, but they do kind of momentarily slow one down because it requires some conscious observing/reading/selecting, which is a problem if diligently working on some edits in a word processor. Dan |
|
From: Philipp K. J. <ja...@ie...> - 2014-10-25 23:19:45
|
> > So, everyone, what is the preferred layout for the window? Is it > like Qt terminal currently is? Would you prefer a single menu button > for "copy to clipboard" (like wxt) with an additional menu button for > saving to a file? Yes. Two different operations, two different buttons (or menu entries, for what it's worth. But since the line of buttons is already there, and is not overcrowded, I'd expect the "save" operation to start from there.) > > For me, I like the copy/paste operations to be very fluent. Saving > to file I can have be a little less fluent. I generally like drop > down menus, but they do kind of momentarily slow one down because it > requires some conscious observing/reading/selecting, which is a > problem if diligently working on some edits in a word processor. |
|
From: Daniel J S. <dan...@ie...> - 2014-10-25 06:04:38
|
On 10/24/2014 06:20 PM, Philipp K. Janert wrote: > > [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. If it is easy. The alternative would--after getting the file name from the dialog box--simply do something like: set term push set term pdf set output 'file_name_from_gui_term_dialog_box' replot set term pop (A "set output push" might be useful, too.) Dan |
|
From: Allin C. <cot...@wf...> - 2014-10-25 20:35:04
|
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. 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 |
|
From: Philipp K. J. <ja...@ie...> - 2014-10-25 20:27:00
|
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 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 > > |
|
From: Jérôme L. <lod...@us...> - 2014-10-25 21:41:50
|
Le 25/10/2014 22:26, Philipp K. Janert a écrit : > 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 different and more complicated than saving an > already rendered bitmap to the clipboard. I had not > appreciated that difficulty sufficiently! (Too bad.) As Bastian said before, the Qt terminal has always had the functionality you are discussing. Its window features an "export as" button, which supports png, svg and pdf. In fact, the Qt terminal remembers every single graphics primitive it receives from gnuplot and is able to render them as a bitmap (on screen, to the clipboard, to a png file) or as a vector graphics (svg, pdf). Because it uses the "QGraphicsScene" feature of Qt, supporting all these options takes no more than a few lines of codes. Jérôme |
|
From: Ethan M. <merritt@u.washington.edu> - 2014-10-25 21:49:44
|
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 |
