gnuplot-beta

File dialog in wxt does not work

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

One other thing - the "file" dialog (top left)
in the wxt terminal does "nothing" for me (either
in iceWM or in Mate). When I click it, nothing
happens.

(By contrast, the file dialog did work in the qt 
dialog under Mate, when I tried it.)

Is this known behavior?

Best,

		Ph.

Re: File dialog in wxt does not work

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

On Friday, 19 September, 2014 13:31:50 Philipp K. Janert wrote:
> 
> One other thing - the "file" dialog (top left)
> in the wxt terminal does "nothing" for me (either
> in iceWM or in Mate). When I click it, nothing
> happens.

It copies the window content into the desktop clipboard.
In KDE you can see it as a small thumbnail in the klipper menu.
Whether IceWM or Mate provide a similar tool to retrieve it, I can't say.  

If you run some other program (Gimp?  Powerpoint? soffice?) that supports 
cut-and-paste using the clipboard, you can then import the image
using ctrl-V or middle-click or whatever you have configured
for "paste from clipboard".

	Ethan

Re: File dialog in wxt does not work

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

On Fri, 19 Sep 2014 13:58:45 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Friday, 19 September, 2014 13:31:50 Philipp K. Janert wrote:
> > 
> > One other thing - the "file" dialog (top left)
> > in the wxt terminal does "nothing" for me (either
> > in iceWM or in Mate). When I click it, nothing
> > happens.
> 
> It copies the window content into the desktop clipboard.
> In KDE you can see it as a small thumbnail in the klipper menu.
> Whether IceWM or Mate provide a similar tool to retrieve it, I can't
> say.  
> 
> If you run some other program (Gimp?  Powerpoint? soffice?) that
> supports cut-and-paste using the clipboard, you can then import the
> image using ctrl-V or middle-click or whatever you have configured
> for "paste from clipboard".

Works! Thanks for the hint.

I expected a "file dialog" to pop up, so that
I could save the graph as a (say) PDF. (As it
works under Qt.)

The functionality is nice, but the user-interface 
might be rather confusing for people. (I doubt I
am the only one who expected a file dialog.)

> 
> 	Ethan
> 

Re: File dialog in wxt does not work

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

On Fri, 19 Sep 2014, Philipp K. Janert wrote:

> On Fri, 19 Sep 2014 13:58:45 -0700
> Ethan A Merritt <sf...@us...> wrote:
>
>> On Friday, 19 September, 2014 13:31:50 Philipp K. Janert wrote:
>>>
>>> One other thing - the "file" dialog (top left)
>>> in the wxt terminal does "nothing" for me (either
>>> in iceWM or in Mate). When I click it, nothing
>>> happens.
>>
>> It copies the window content into the desktop clipboard.
>> In KDE you can see it as a small thumbnail in the klipper menu.
>> Whether IceWM or Mate provide a similar tool to retrieve it, I can't
>> say.
>>
>> If you run some other program (Gimp?  Powerpoint? soffice?) that
>> supports cut-and-paste using the clipboard, you can then import the
>> image using ctrl-V or middle-click or whatever you have configured
>> for "paste from clipboard".
>
> Works! Thanks for the hint.
>
> I expected a "file dialog" to pop up, so that
> I could save the graph as a (say) PDF. (As it
> works under Qt.)
>
> The functionality is nice, but the user-interface
> might be rather confusing for people. (I doubt I
> am the only one who expected a file dialog.)

The icon at the top left is supposed to represent "copy" and a 
clipboard, and its tooltip says "Copy the plot to clipboard". I'm
not sure why one would expect a "file dialog".

Allin Cottrell

Re: File dialog in wxt does not work

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

[snip]

> > The functionality is nice, but the user-interface
> > might be rather confusing for people. (I doubt I
> > am the only one who expected a file dialog.)
> 
> The icon at the top left is supposed to represent "copy" and a 
> clipboard, and its tooltip says "Copy the plot to clipboard". I'm
> not sure why one would expect a "file dialog".

Answer: because that's what is in the top-left corner
of menus, almost universally. (Eg, among many others,
gnuplot's own wxt terminal.)

The icon is too small and to unspecific to send a 
strong message, either way. And I admit that I did
not wait for the tooltip.

I mean, once you know what's it doing, it's no 
problem, but otherwise, it's not at all obvious.

> 
> Allin Cottrell

Re: File dialog in wxt does not work

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

On Fri, 19 Sep 2014, Philipp K. Janert wrote:

> [snip]
>
>>> The functionality is nice, but the user-interface
>>> might be rather confusing for people. (I doubt I
>>> am the only one who expected a file dialog.)
>>
>> The icon at the top left is supposed to represent "copy" and a
>> clipboard, and its tooltip says "Copy the plot to clipboard". I'm
>> not sure why one would expect a "file dialog".
>
> Answer: because that's what is in the top-left corner
> of menus, almost universally. (Eg, among many others,
> gnuplot's own wxt terminal.)
>
> The icon is too small and to unspecific to send a
> strong message, either way. And I admit that I did
> not wait for the tooltip.

Granted, top-left corner is usually File/<something or other> and 
the icon is not immediately recognizable. But I'm not sure what the 
"solution" is: maybe move the icon off the top-left corner, and/or 
add feedback in the form of a "Plot copied to clipboard" message 
box?

Actually, I'll agree with Philipp: nothing about the GUI options in 
the wxt plot window is immediately clear. For example, what is the 
cross-hair cursor supposed to do, as you move it around?

Allin Cottrell

Re: File dialog in wxt does not work

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

On Fri, 19 Sep 2014 19:55:45 -0400 (EDT)
Allin Cottrell <cot...@wf...> wrote:

> On Fri, 19 Sep 2014, Philipp K. Janert wrote:
> 
> > [snip]
> >
> >>> The functionality is nice, but the user-interface
> >>> might be rather confusing for people. (I doubt I
> >>> am the only one who expected a file dialog.)
> >>
> >> The icon at the top left is supposed to represent "copy" and a
> >> clipboard, and its tooltip says "Copy the plot to clipboard". I'm
> >> not sure why one would expect a "file dialog".
> >
> > Answer: because that's what is in the top-left corner
> > of menus, almost universally. (Eg, among many others,
> > gnuplot's own wxt terminal.)
> >
> > The icon is too small and to unspecific to send a
> > strong message, either way. And I admit that I did
> > not wait for the tooltip.
> 
> Granted, top-left corner is usually File/<something or other> and 
> the icon is not immediately recognizable. But I'm not sure what the 
> "solution" is: maybe move the icon off the top-left corner, and/or 
> add feedback in the form of a "Plot copied to clipboard" message 
> box?

Those were the two ideas that came to my mind, too.
Additionally, I think the icon could be much enhanced
with the addition of a big red arrow from the graph to
the clipboard. In fact, I'd interchange the current 
positions of the graph and the clipboard in the icon,
so that the arrow would align with the typical (western)
workflow "left to right". 

Another idea is to change the functionality - I am not so 
familiar with the capabilities of wxt, but would it be
possible to save the graph to PDF/PNG immediately, rather
than (merely) to the clipboard? This would naturally lead
to a file-selection dialog, as in the qt terminal.

I should add that I really like this feature in principle,
because the workflow of saving (actually: exporting) graphs 
from gnuplot has always been a bit awkward (5 steps: set t, 
set o, replot, set o, set t). So, being able to do it all
in one mouse-click is a huge improvement (in my opinion),
and also brings gnuplot's behavior closer to what current
users have come to expect from applications.

> 
> Actually, I'll agree with Philipp: nothing about the GUI options in 
> the wxt plot window is immediately clear. For example, what is the 
> cross-hair cursor supposed to do, as you move it around?
> 
> Allin Cottrell

Re: File dialog in wxt does not work

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

On Saturday, 20 September 2014 07:51:54 AM pl...@pi... wrote:
>
> Firing up Gimp, just to do a paste and then use its file "export"
> dialogue is a time waster.

That would indeed be a time waster.  But at least in KDE, hitting the
"print screen" key brings up a widget where you can save to a file
the entire screen, the content of one window, or an arbitrary rectangle.
I believe Gnome provides an equivalent option via gnome-utils.
I don't know what's available of that sort on the IceWM that Philip
is using.

	Ethan

Re: File dialog in wxt does not work

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

On Sat, 20 Sep 2014 09:24:30 -0700
sfeam <sf...@us...> wrote:

> On Saturday, 20 September 2014 07:51:54 AM pl...@pi... wrote:
> >
> > Firing up Gimp, just to do a paste and then use its file "export"
> > dialogue is a time waster.
> 
> That would indeed be a time waster.  But at least in KDE, hitting the
> "print screen" key brings up a widget where you can save to a file
> the entire screen, the content of one window, or an arbitrary
> rectangle. I believe Gnome provides an equivalent option via
> gnome-utils. I don't know what's available of that sort on the IceWM
> that Philip is using.
> 

Naive question on the entire saving/clipboard 
issue: what actually is being saved? Is this 
in any way different than taking a screenshot?
(Because, if it's not more than a screenshot,
then gnuplot does not need to implement anything,
really - there are plenty of screenshot utilities
out there.)

When using the "classic" method (set t ..., set o, 
replot, etc), it's very specific regarding the size
and resolution of the bitmap or vector image that 
is being saved. Is there any control over these
qualities when copying to clipboard?

Best,

		Ph.

Re: File dialog in wxt does not work

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

On 09/20/14 02:28, Philipp K. Janert wrote:
> Those were the two ideas that came to my mind, too.
> Additionally, I think the icon could be much enhanced
> with the addition of a big red arrow from the graph to
> the clipboard. In fact, I'd interchange the current
> positions of the graph and the clipboard in the icon,
> so that the arrow would align with the typical (western)
> workflow "left to right".

Oh, for pity's sake no more dumb-assed,  " you have just pressed X", 
"are you sure" windozian messages.

I do not want half my work flow to be dismissing stupid messages telling 
what I've just done.

This is all part of the universal obscurity-by-icons problem. Thirty 
year ago it would have been the word "copy" , now everything has to be 
an icon. In the pressure to save space the icons have to be small and 
therefore have limited means of communicating anything. They are just 
enough to be reminders once you know what the interface does.

That's what tool-tips are for. That is a fairly standard, cross platform 
technique.If you don't know what something does , hover.

The "top left" convention is for MENUS, this is an icon tool bar. There 
is no convention that says the first entry on a tool bar should bring up 
a file_open dialogue.

Sorry, Philipp, you just fooled yourself by making unfounded assumptions 
that wxt would do the same thing and the qt terminal instead of trying 
to discover what the (new to you ) interface did.

I've been using wxt pretty much all along with gnuplot and did not find 
this feature at first, until the day I decided to find out what all the 
buttons did. The tool-tips soon made it clear.

This is a very useful feature and it is very useful in that it gives you 
exactly what you are looking at. I use this almost exclusively for 
creating permanent copy of my graphs since the png terminal produce 
something so different from what is on the screen.: different fonts, 
different line widths, different colours....  Usually by the time I get 
to want output, I've got the graph looking the way I need it. I do not 
want something else stored or in hardcopy.

Now if qt allows saving the _screen image_ of the graph in png or 
similar format, this would be a good addition to wxt. Firing up Gimp, 
just to do a paste and then use its file "export" dialogue is a time 
waster.

Adding a 'save to file' icon that takes the same image that goes to 
clipboard would be good enhancement, should anyone feel inclined.

Peter.


>
> Another idea is to change the functionality - I am not so
> familiar with the capabilities of wxt, but would it be
> possible to save the graph to PDF/PNG immediately, rather
> than (merely) to the clipboard? This would naturally lead
> to a file-selection dialog, as in the qt terminal.
>
> I should add that I really like this feature in principle,
> because the workflow of saving (actually: exporting) graphs
> from gnuplot has always been a bit awkward (5 steps: set t,
> set o, replot, set o, set t). So, being able to do it all
> in one mouse-click is a huge improvement (in my opinion),
> and also brings gnuplot's behavior closer to what current
> users have come to expect from applications.
>
>> >
>> >Actually, I'll agree with Philipp: nothing about the GUI options in
>> >the wxt plot window is immediately clear. For example, what is the
>> >cross-hair cursor supposed to do, as you move it around?
>> >
>> >Allin Cottrell

Re: File dialog in wxt does not work

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

On Sat, 20 Sep 2014 07:51:54 +0200
pl...@pi... wrote:

> On 09/20/14 02:28, Philipp K. Janert wrote:
> > Those were the two ideas that came to my mind, too.
> > Additionally, I think the icon could be much enhanced
> > with the addition of a big red arrow from the graph to
> > the clipboard. In fact, I'd interchange the current
> > positions of the graph and the clipboard in the icon,
> > so that the arrow would align with the typical (western)
> > workflow "left to right".
> 
> Oh, for pity's sake no more dumb-assed,  " you have just pressed X", 
> "are you sure" windozian messages.
> 
> I do not want half my work flow to be dismissing stupid messages
> telling what I've just done.

I can agree with that.

> 
> This is all part of the universal obscurity-by-icons problem. Thirty 
> year ago it would have been the word "copy" , now everything has to
> be an icon. In the pressure to save space the icons have to be small
> and therefore have limited means of communicating anything. They are
> just enough to be reminders once you know what the interface does.

I can agree with that, too - but what are
you gonna do about it?

> 
> That's what tool-tips are for. That is a fairly standard, cross
> platform technique.If you don't know what something does , hover.

The problem was that I didn't know I didn't know.
I was certain (though wrong) that I knew what it
did. And I have had enough trouble with gnuplot
terminals that, when I got no visible response, 
I assumed that there was a malfunction/bug, rather 
than a misuse on my part.

> 
> The "top left" convention is for MENUS, this is an icon tool bar.
> There is no convention that says the first entry on a tool bar should
> bring up a file_open dialogue.
> 
> Sorry, Philipp, you just fooled yourself by making unfounded
> assumptions that wxt would do the same thing and the qt terminal
> instead of trying to discover what the (new to you ) interface did.

I disagree. "Top left" is a sufficiently widely followed 
convention, even for icon bars, that I cannot accept the
"unfounded assumption" statement.

> 
> I've been using wxt pretty much all along with gnuplot and did not
> find this feature at first, until the day I decided to find out what
> all the buttons did. The tool-tips soon made it clear.
>
> This is a very useful feature and it is very useful in that it gives
> you exactly what you are looking at. I use this almost exclusively
> for creating permanent copy of my graphs since the png terminal
> produce something so different from what is on the screen.: different
> fonts, different line widths, different colours....  Usually by the
> time I get to want output, I've got the graph looking the way I need
> it. I do not want something else stored or in hardcopy.

Question for you: what do you choose to paste the copy into?
Gimp? Or something else? Any experience to share?

> 
> Now if qt allows saving the _screen image_ of the graph in png or 
> similar format, this would be a good addition to wxt. Firing up Gimp, 
> just to do a paste and then use its file "export" dialogue is a time 
> waster.
> 
> Adding a 'save to file' icon that takes the same image that goes to 
> clipboard would be good enhancement, should anyone feel inclined.

Thanks.

> 
> Peter.
> 
> 
> >
> > Another idea is to change the functionality - I am not so
> > familiar with the capabilities of wxt, but would it be
> > possible to save the graph to PDF/PNG immediately, rather
> > than (merely) to the clipboard? This would naturally lead
> > to a file-selection dialog, as in the qt terminal.
> >
> > I should add that I really like this feature in principle,
> > because the workflow of saving (actually: exporting) graphs
> > from gnuplot has always been a bit awkward (5 steps: set t,
> > set o, replot, set o, set t). So, being able to do it all
> > in one mouse-click is a huge improvement (in my opinion),
> > and also brings gnuplot's behavior closer to what current
> > users have come to expect from applications.
> >
> >> >
> >> >Actually, I'll agree with Philipp: nothing about the GUI options
> >> >in the wxt plot window is immediately clear. For example, what is
> >> >the cross-hair cursor supposed to do, as you move it around?
> >> >
> >> >Allin Cottrell
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: File dialog in wxt does not work

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

On 09/20/14 18:36, Philipp K. Janert wrote:
> Naive question on the entire saving/clipboard
> issue: what actually is being saved? Is this
> in any way different than taking a screenshot?
> (Because, if it's not more than a screenshot,
> then gnuplot does not need to implement anything,
> really - there are plenty of screenshot utilities
> out there.)
>

As Ethan correctly points out, there are clipboard widgets in the 
mastodon window managers like KDE and Gnome. Like Philipp I use a 
lightweight WM that does not have loads of bells and whistles.

There is probably some small clipboard util. that I could use if I dug 
around. Firing up Gimp is a hammer/walnut solution.

The difference in what yor get is that with a screen-shot util. you get 
the window borders, icons, menus etc. unless you  try to manually select 
exactly the area you want, which is hard to get exactly right and is 
time consuming.



> When using the "classic" method (set t ..., set o,
> replot, etc), it's very specific regarding the size
> and resolution of the bitmap or vector image that
> is being saved. Is there any control over these
> qualities when copying to clipboard?

In theory , set term wxt size 800,300  determines the terminal window 
size, hence what is copied, by any technique, from the screen output. 
Also FVWM can display the window size during drag to get an exact 
desired window size.

However, while consistent, I find here that it does not give the 
requested size eg 800,300 gives me a window 700,255 !  x always loses 
100 px :?

I find the terminal size that gives me the required clipboard image to 
work around that problem. Maybe I should raise a bug about that.

Using set t png; set output "fn"; replot  produces significantly 
different results to what is on the screen which, as I detailed earlier, 
is why I no longer use the gnuplot ong etc  terminals to produce 
permanent output.

I ought to find a more efficient way of saving clipboard to file.

regards. Peter




>
> Best,
>
> 		Ph.

Re: File dialog in wxt does not work

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

[snip]

> 
> > When using the "classic" method (set t ..., set o,
> > replot, etc), it's very specific regarding the size
> > and resolution of the bitmap or vector image that
> > is being saved. Is there any control over these
> > qualities when copying to clipboard?
> 
> In theory , set term wxt size 800,300  determines the terminal window 
> size, hence what is copied, by any technique, from the screen output. 
> Also FVWM can display the window size during drag to get an exact 
> desired window size.
> 

Since this whole functionality is new to me, I am trying
to make sure I am really getting it. I it possible to 
generate genuine vector graphics this way (that is, going 
through the clipboard)? Or are the results invariably pixelated?

I just tried to export a graph to PDF, by copying to 
clipboard and then pasting into inkscape - when blown
up, the results are definitely pixelated (which they
would not be with "genuine" PDF).

So, is it fair to say that the copy-to-clipboard tactic
gets me exactly the graph I see - as a pixmap -, but that
if I want vector graphics, the classic set t pdfcairo, etc
strategy is the way to go?

Re: File dialog in wxt does not work

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

On Sunday, 21 September 2014 09:31:52 AM Philipp K. Janert wrote:
> 
> [snip]
> 
> > 
> > > When using the "classic" method (set t ..., set o,
> > > replot, etc), it's very specific regarding the size
> > > and resolution of the bitmap or vector image that
> > > is being saved. Is there any control over these
> > > qualities when copying to clipboard?
> > 
> > In theory , set term wxt size 800,300  determines the terminal window 
> > size, hence what is copied, by any technique, from the screen output. 
> > Also FVWM can display the window size during drag to get an exact 
> > desired window size.
> > 
> 
> Since this whole functionality is new to me, I am trying
> to make sure I am really getting it. I it possible to 
> generate genuine vector graphics this way (that is, going 
> through the clipboard)?

It is technically possible.  For instance on Windows the clipboard
holds blocks of WMF or EMF (or at least it used to, I have not used
Windows for many years).  In principle an application can stuff
arbitrary data into a clipboard, but in practice it's usually 
either pure text or a bitmap image.  Current the wxt terminal
stuffs a bitmap image to the clipboard.  Here is the code:

        wxTheClipboard->UsePrimarySelection(false);
        /* SetData clears the clipboard */
        if ( wxTheClipboard->Open() ) {
                wxTheClipboard->SetData(new wxBitmapDataObject(cp_bitmap));
                wxTheClipboard->Close();
        }
        wxTheClipboard->Flush();

I think it would be straightforward to have the wxt terminal offer
the same output widget options as the qt terminal:  png/pdf/svg output
of the current plot contents triggered from the GUI.   There is a nice
comparison of how to generate the various output modes here:

		http://zetcode.com/gfx/cairo/cairobackends/

In this case you probably would want to export to a file rather than 
to the clipboard, just because most applications on the receiving end
probably won't know what to do with a block of svg (for instance) 
pulled from the clipboard.  But Inkscape might. 

> I just tried to export a graph to PDF, by copying to 
> clipboard and then pasting into inkscape - when blown
> up, the results are definitely pixelated (which they
> would not be with "genuine" PDF).

Inkscape is an SVG tool.  It can import bitmap images,
but I don't think it knows how to convert PDF to SVG.
In fact I don't know of any tool that does this.
 
> So, is it fair to say that the copy-to-clipboard tactic
> gets me exactly the graph I see - as a pixmap -, but that
> if I want vector graphics, the classic set t pdfcairo, etc
> strategy is the way to go?

That's what I do in practice.  I find that the pdfcairo output
is nearly identical to the wxt screen display content if you
specify an appropriate size for the pdf canvas.  But as noted
above this could probably be automated via a GUI widget.
Patches welcome.

	Ethan

Re: File dialog in wxt does not work

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

On Sun, 21 Sep 2014 10:39:55 -0700
sfeam <sf...@us...> wrote:

Thanks for the explanation!


> On Sunday, 21 September 2014 09:31:52 AM Philipp K. Janert wrote:
> > 
> > [snip]
> > 
> > > 
> > > > When using the "classic" method (set t ..., set o,
> > > > replot, etc), it's very specific regarding the size
> > > > and resolution of the bitmap or vector image that
> > > > is being saved. Is there any control over these
> > > > qualities when copying to clipboard?
> > > 
> > > In theory , set term wxt size 800,300  determines the terminal
> > > window size, hence what is copied, by any technique, from the
> > > screen output. Also FVWM can display the window size during drag
> > > to get an exact desired window size.
> > > 
> > 
> > Since this whole functionality is new to me, I am trying
> > to make sure I am really getting it. I it possible to 
> > generate genuine vector graphics this way (that is, going 
> > through the clipboard)?
> 
> It is technically possible.  For instance on Windows the clipboard
> holds blocks of WMF or EMF (or at least it used to, I have not used
> Windows for many years).  In principle an application can stuff
> arbitrary data into a clipboard, but in practice it's usually 
> either pure text or a bitmap image.  Current the wxt terminal
> stuffs a bitmap image to the clipboard.  Here is the code:
> 
>         wxTheClipboard->UsePrimarySelection(false);
>         /* SetData clears the clipboard */
>         if ( wxTheClipboard->Open() ) {
>                 wxTheClipboard->SetData(new
> wxBitmapDataObject(cp_bitmap)); wxTheClipboard->Close();
>         }
>         wxTheClipboard->Flush();
> 
> I think it would be straightforward to have the wxt terminal offer
> the same output widget options as the qt terminal:  png/pdf/svg output
> of the current plot contents triggered from the GUI.   There is a nice
> comparison of how to generate the various output modes here:
> 
> 		http://zetcode.com/gfx/cairo/cairobackends/
> 
> In this case you probably would want to export to a file rather than 
> to the clipboard, just because most applications on the receiving end
> probably won't know what to do with a block of svg (for instance) 
> pulled from the clipboard.  But Inkscape might. 
> 
> > I just tried to export a graph to PDF, by copying to 
> > clipboard and then pasting into inkscape - when blown
> > up, the results are definitely pixelated (which they
> > would not be with "genuine" PDF).
> 
> Inkscape is an SVG tool.  It can import bitmap images,
> but I don't think it knows how to convert PDF to SVG.
> In fact I don't know of any tool that does this.
>  
> > So, is it fair to say that the copy-to-clipboard tactic
> > gets me exactly the graph I see - as a pixmap -, but that
> > if I want vector graphics, the classic set t pdfcairo, etc
> > strategy is the way to go?
> 
> That's what I do in practice.  I find that the pdfcairo output
> is nearly identical to the wxt screen display content if you
> specify an appropriate size for the pdf canvas.  But as noted
> above this could probably be automated via a GUI widget.
> Patches welcome.
> 
> 	Ethan
> 
> 
> 
> 
>