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

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On 10/27/14 19:53, Ethan A Merritt wrote:
> I've added to cvs for 5.0 and 5.1 a toggle button in the wxt tools widget.
>
> The very first time you use it, the state of the toggle button may not be
> reported correctly because the corresponding state variable doesn't exist
> in your previous saved-state file.  But once you've exited the program
> that first time, causing the saved-state to be updated, everything should work
> correcly in subsequent sessions.
>
> I also have code to add save-to-png-file to the wxt toolbar.
> But I haven't worked with this toolkit before and I haven't found a
> decent worked example to show how to embed this in a pull-down menu.
> So as before ...
>
>> >Patches welcome.
> 	Ethan
>

Nice addition Ethan, thanks for putting that in. Having to hit replot 
every time I resize wxt was always a drag but never seemed important 
enough to mention.  I'm not sure what purpose there is in the toggle 
option, when is it useful to have the plot temporarily not match the new 
terminal size?  Surely if the user resizes the terminal it is with the 
intention to resize the graph, which will happen next time anything is 
plotted or replotted.

I'm not a hard-line GUI minimalist but this toggle seems like feature 
clutter.

Peter.

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On Friday, 24 October, 2014 22:17:19 sfeam wrote:
> On Saturday, 25 October 2014 12:01:57 AM Daniel J Sebald wrote:
> > On 10/24/2014 05:04 PM, Ethan A Merritt wrote:
> > > On Friday, 24 October, 2014 15:17:01 Daniel J Sebald wrote:
> > >> 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.
> 
> Ah, I understand.
> See Feature Request #314
> 
> The new aspect ratio isn't applied until the next replot.
> The qt terminal has a tool widget to toggle whether you
> want this to happen automatically.  The wxt should have one also.

I've added to cvs for 5.0 and 5.1 a toggle button in the wxt tools widget.

The very first time you use it, the state of the toggle button may not be
reported correctly because the corresponding state variable doesn't exist
in your previous saved-state file.  But once you've exited the program
that first time, causing the saved-state to be updated, everything should work
correcly in subsequent sessions.

I also have code to add save-to-png-file to the wxt toolbar.
But I haven't worked with this toolkit before and I haven't found a
decent worked example to show how to embed this in a pull-down menu. 
So as before ...

> Patches welcome.

	Ethan

Re: RC5 proposal: Cleaning up "plot smooth"?

[Hans-Bernhard B. <HBB...@t-...>]

[Dang it, forgot to CC list, again!]

Am 26.10.2014 um 18:15 schrieb Philipp K. Janert:

> The only reason that they all are presented to
> the user as "smooth" options is that they all
> are implemented using similar facilities, but
> not because they are logically similar.

Actually, it's much more prosaic than that.  When the keyword was
created, all the algorithms it chose actually did smooth data (i.e. they
were interpolators).  The other ones, that do other kinds of data
transformation, just got plugged into the existing socket because it was
there.

> Question: would it make sense to break this up
> now, before it gets any bigger? And if yes: how?

IMHO, it wouldn't.  It might make sense to rename this option, though.
Either "filter" or "transform" would capture the actual intent better
than "smooth".  And dgrid3d could become our first "filter" algorithm
for splot, while at it.

RC5 proposal: Cleaning up "plot smooth"?

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

The "plot smooth" facility has grown over time;
currently it has eleven (11) suboptions, and I
can see this number to grow even more.

What's more, these suboptions do quite different
things. I can identify four major groups:

1) smooth interpolations:
  csplines, acsplines, mcsplines, bezier, sbezier

2) visualization of point distributions
  kdens, cumulative, cnormal

3) dedupe
  frequency, unique

4) unwrap 
  (which I have not yet figured out how to use)

The only reason that they all are presented to 
the user as "smooth" options is that they all
are implemented using similar facilities, but 
not because they are logically similar. (In 
particular items 1 and 2 do quite different 
things. And it's not even as if all of the 
suboptions add a "smooth curve" to the data - 
items 3 and 4 do not!).

Question: would it make sense to break this up
now, before it gets any bigger? And if yes: how?

Since introducing new keyword(s) would imply a
possibly non-backwards compatible change, now is
the time to think about it!

Here is one suggestion (total strawman - just to
get the discussion going):

item 1: plot smooth ... (interpolations)
item 2: plot distrib ... (point distributions)
item 3: plot dedupe ... (?)
item 4: plot unwrap ...

Full plot commands would then look like:

plot "data" u 1:2 smooth csplines 
plot "data" u 1:2 distrib kdens
plot "data" u 1:2 dedupe unique

and so on.

Question: is this a good idea? And: is this worth it?

More importantly: is there some refactoring that
could/should occur at the same time on the 
implementation side? 

One thing I foresee is that people will continue
to add additional algorithms (3 have been added 
since I last looked) - for instance, I am toying
with an algorithm to do LOWESS interpolation, and
I can also see the desire to add new smoothing
kernels to kdens. And on and on.

Would it make sense to pull things apart now, both
from the user-interface point of view, and on the
implementation side?

Best,

		Ph.

Fwd: Re: Proposal: Saving graphs from Qt and wxt terminals

[Hans-Bernhard B. <HBB...@t-...>]

[Ooops, forgot to CC the list...]

Am 25.10.2014 um 23:18 schrieb Ethan Merritt:
> 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:

>  > I guess the question then becomes: in what form is
>  > the graph information is available "when the button
>  > is pressed".

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

That sounds like it's essentially the same way the Windows terminal
implemented both copy-to-clipboard and the "screendump" command.

The outboard driver (it used to be a DLL, back in 16-bit days) stores
the graphics commands it received from win.trm (function GraphOp()) as
struct GWOP in a linked list of arrays (struct GWOPBLK).  This entire
sequence then gets "played" by function win/wgraph.c::drawgraph() onto a
"context", which can be a screen window, a printer device, or a WMF to
be handed over to the clipboard.

Good to see the "modern" drivers catching up --- about 20 years later ;-P

Re: Proposal: Saving graphs from Qt and wxt terminals

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

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

Re: Proposal: Saving graphs from Qt and wxt terminals

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

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

Re: Simultaneous qt and wxt terms (was Re: Proposal: Saving graphs from Qt and wxt terminals)

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

On Saturday, 25 October 2014 04:46:23 PM Daniel J Sebald wrote:
> On 10/25/2014 03:01 PM, sfeam wrote:
> > On Saturday, 25 October 2014 01:25:51 PM Daniel J Sebald wrote:
> >
> >>  On 10/25/2014 01:05 PM, Bastian Märkisch wrote:
> >
> >>  > Am 25.10.2014 um 19:46 schrieb Daniel J Sebald:
> >
> >>  >> On 10/25/2014 03:40 AM, Daniel J Sebald wrote:
> >
> >>  >>
> >
> >>  >>> I removed the interlock test and it creates quite a mess with invalid
> >
> >>  >>> events, seg faults in bad library calls, to scratch the surface.
> >
> >>  >>>
> >
> >>  >>> Investigating a bit, I think the problem lies in the fact wxt terminal
> >
> >>  >>> is not in its own process.
> >
> >>  >>
> >
> >>  >> It's too much work to do this in an afternoon or so. Having looked at
> >
> >>  >> the code, though, I'd say some things get simplified when WXT is run in
> >
> >>  >> its own process as an outboard plotter. All these sorts of conditions
> >
> >>  >>
> >
> >>  >> #if defined(WXT_MONOTHREADED) || defined(_Windows)
> >
> >>  >>
> >
> >>  >> go away.
> >
> >>  >>
> >
> >>  >> Dan
> >
> >>  >
> >
> >>  > Btw. Timothée had been working on this years ago, see patch #380
> >
> >>  > https://sourceforge.net/p/gnuplot/patches/380
> >
> >>
> >
> >>  Thanks. That could save a ton on the initial tedious work of putting
> >
> >>  bulk of the code in its own program.
> >
> >>
> >
> >>
> >
> >>  > Also, the qt and wxt terminals run nicely in the same session on
> >
> >>  > Windows. It just took some effort to make qt->waitforinput() work.
> >
> >>  >
> >
> >>  > Since waitforinput() is a terminal routine it typically only handles
> >
> >>  > events from the library the current terminal uses. If we want to use
> >
> >>  > multiple libraries in the same process, we need to replace/extend that
> >
> >>  > mechanism.
> >
> >>
> >
> >>  I think once the active terminal is changed, mousing and keyboard input
> >
> >>  is disabled for others.
> >
> >>
> >
> >>
> >
> >>  > From my experience with the (outboard) qt terminal, I sincerely doubt
> >
> >>  > that moving the wxt terminal to its own process will significantly
> >
> >>  > simplify the source.
> >
> >>
> >
> >>  It won't simplify the source, but it will get rid of those "corner
> >
> >>  cases". As you point out, Windows works fine for both terminals...and
> >
> >>  that's why the things like:
> >
> >>
> >
> >>  #if defined(WXT_MONOTHREADED) || defined(_Windows)
> >
> > Before tearing into a project to split off wxt into a separate process
> >
> > altogether, I think you should look into making the WXT_MONOTHREADED
> >
> > variant work on linux. Some/all of the problems it now has are due to
> >
> > the graphics event loop running in a separate thread.
> 
> I know that Qt has a requirement that graphics be only in the main 
> thread.  I can't verify that is the case for wxWidgets and I see some 
> discussion on the Web that graphics can be done in non-main threads 
> (sometimes with extra initialization inside the other threads).
> 
> In any case, is that the desired setup?  To have interactive graphics 
> running in the same thread?  Doesn't that create some event management 
> code that typically is averted by using separate threads or processes?
> 
> One approach might be to put what is now the main thread/code for 
> processing command line input into a separate thread and then leaving 
> the main thread for a possible interactive terminal, but not sure I like 
> that idea.
> 
> 
> > Anyhow, I really don't see the need for typical users to switch between
> >
> > qt and wxt within a single gnuplot session. Especially because the
> >
> > distro-packaged gnuplot versions probably only provide one or the other,
> >
> > not both. It can be handy for a developer, yes, because you'd like to
> >
> > compare the output of the two terminals. But I don't think that's a
> >
> > particularly useful thing for a typical gnuplot session.
> >
> > So really I think this is low priority compared to some other issues.
> >
> > For instance, how about fixing the auto-scaling for image plots?
> >
> > Right now the default behavior is to auto-scale to the center of
> >
> > the 4 corner pixels, which clips all the outermost pixels in half.
> >
> > That would be OK if there were an easy way to override it, but
> >
> > many of the obvious commands don't work.
> >
> > E.g.
> >
> > set xrange [-0.5:*] # doesn't work with image data
> >
> > set offset .5, .5, .5, .5 # this doesn't work either
> 
> Could you give an example?

Sure. Based on the 1st plot in heatmaps.dem

%%%%%%
unset key
set tic scale 0

# Color runs from white to green
set palette rgbformula -7,2,-7
set cbrange [0:5]
unset cbtics

$map1 << EOD
5 4 3 1 0
2 2 0 0 1
0 0 0 1 0
0 0 0 2 3
0 1 2 4 3
EOD

set view map
set multiplot layout 1,2

set title "auto-scaled"
splot '$map1' matrix with image

set xrange [-0.5:4.5]
set yrange [-0.5:4.5]

set title "explicit set xrange [-0.5:4.5]"
replot

unset multiplot

pause -1
%%%%%%

	Ethan

> 
> This works on my system:
> 
> reset
> set xrange [-0.5:*]
> set cbrange [0:1]
> unset key
> set tics out
> plot '-' with rgbimage
> 0 0 0.0 0.0 0.5
> 0 1 0.0 0.5 0.0
> 1 0 0.5 0.0 0.5
> 1 1 0.0 0.5 0.5
> e
> 
> Although, I would point out that the Qt terminal doesn't quite layout of 
> the pixels correctly.  The left column pixels are about 5% to 10% too 
> wide and overlap the right column pixels.  The wxt terminal is better at 
> this, but I notice that wxt has some problems when scaling the plot 
> size.  Sometimes there is a small white space between the axes and image.
> 
> This sort of works:
> 
> reset
> set offset 0.5, 0.5, 0.5, 0.5
> set cbrange [0:1]
> unset key
> set tics out
> plot '-' with rgbimage
> 0 0 0.0 0.0 0.5
> 0 1 0.0 0.5 0.0
> 1 0 0.5 0.0 0.5
> 1 1 0.0 0.5 0.5
> e
> 
> but it seems to me that a 0.5 border is created, but then the autorange 
> is taking that extra space to compute nice round numbers a little bigger 
> than the 0.5 border, i.e., [-1:2].
> 
> We should come up with a definition for the image pixel coordinate 
> system, if that hasn't already been done.  I'm recalling confusion about 
> one of us thinking in terms of pixel centers, while the other in terms 
> of pixels at the coordinate system leading edge.  They're both valid and 
> the choice is somewhat arbitrary, but it would be nice to have the 
> accepted spatial coordinate system written down so that when programming 
> there's no doubt about how to program computations.  We should have:
> 
> 1) A fairly detailed statement in a code file or a text file.
> 
> 2) An intricate demo plotting an image along with some lines and arrow 
> describing what the convention is.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> 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

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

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

Re: Proposal: Saving graphs from Qt and wxt terminals

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

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

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

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

	Ethan


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

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

Re: Simultaneous qt and wxt terms (was Re: Proposal: Saving graphs from Qt and wxt terminals)

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

On 10/25/2014 03:01 PM, sfeam wrote:
> On Saturday, 25 October 2014 01:25:51 PM Daniel J Sebald wrote:
>
>>  On 10/25/2014 01:05 PM, Bastian Märkisch wrote:
>
>>  > Am 25.10.2014 um 19:46 schrieb Daniel J Sebald:
>
>>  >> On 10/25/2014 03:40 AM, Daniel J Sebald wrote:
>
>>  >>
>
>>  >>> I removed the interlock test and it creates quite a mess with invalid
>
>>  >>> events, seg faults in bad library calls, to scratch the surface.
>
>>  >>>
>
>>  >>> Investigating a bit, I think the problem lies in the fact wxt terminal
>
>>  >>> is not in its own process.
>
>>  >>
>
>>  >> It's too much work to do this in an afternoon or so. Having looked at
>
>>  >> the code, though, I'd say some things get simplified when WXT is run in
>
>>  >> its own process as an outboard plotter. All these sorts of conditions
>
>>  >>
>
>>  >> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>
>>  >>
>
>>  >> go away.
>
>>  >>
>
>>  >> Dan
>
>>  >
>
>>  > Btw. Timothée had been working on this years ago, see patch #380
>
>>  > https://sourceforge.net/p/gnuplot/patches/380
>
>>
>
>>  Thanks. That could save a ton on the initial tedious work of putting
>
>>  bulk of the code in its own program.
>
>>
>
>>
>
>>  > Also, the qt and wxt terminals run nicely in the same session on
>
>>  > Windows. It just took some effort to make qt->waitforinput() work.
>
>>  >
>
>>  > Since waitforinput() is a terminal routine it typically only handles
>
>>  > events from the library the current terminal uses. If we want to use
>
>>  > multiple libraries in the same process, we need to replace/extend that
>
>>  > mechanism.
>
>>
>
>>  I think once the active terminal is changed, mousing and keyboard input
>
>>  is disabled for others.
>
>>
>
>>
>
>>  > From my experience with the (outboard) qt terminal, I sincerely doubt
>
>>  > that moving the wxt terminal to its own process will significantly
>
>>  > simplify the source.
>
>>
>
>>  It won't simplify the source, but it will get rid of those "corner
>
>>  cases". As you point out, Windows works fine for both terminals...and
>
>>  that's why the things like:
>
>>
>
>>  #if defined(WXT_MONOTHREADED) || defined(_Windows)
>
> Before tearing into a project to split off wxt into a separate process
>
> altogether, I think you should look into making the WXT_MONOTHREADED
>
> variant work on linux. Some/all of the problems it now has are due to
>
> the graphics event loop running in a separate thread.

I know that Qt has a requirement that graphics be only in the main 
thread.  I can't verify that is the case for wxWidgets and I see some 
discussion on the Web that graphics can be done in non-main threads 
(sometimes with extra initialization inside the other threads).

In any case, is that the desired setup?  To have interactive graphics 
running in the same thread?  Doesn't that create some event management 
code that typically is averted by using separate threads or processes?

One approach might be to put what is now the main thread/code for 
processing command line input into a separate thread and then leaving 
the main thread for a possible interactive terminal, but not sure I like 
that idea.


> Anyhow, I really don't see the need for typical users to switch between
>
> qt and wxt within a single gnuplot session. Especially because the
>
> distro-packaged gnuplot versions probably only provide one or the other,
>
> not both. It can be handy for a developer, yes, because you'd like to
>
> compare the output of the two terminals. But I don't think that's a
>
> particularly useful thing for a typical gnuplot session.
>
> So really I think this is low priority compared to some other issues.
>
> For instance, how about fixing the auto-scaling for image plots?
>
> Right now the default behavior is to auto-scale to the center of
>
> the 4 corner pixels, which clips all the outermost pixels in half.
>
> That would be OK if there were an easy way to override it, but
>
> many of the obvious commands don't work.
>
> E.g.
>
> set xrange [-0.5:*] # doesn't work with image data
>
> set offset .5, .5, .5, .5 # this doesn't work either

Could you give an example?

This works on my system:

reset
set xrange [-0.5:*]
set cbrange [0:1]
unset key
set tics out
plot '-' with rgbimage
0 0 0.0 0.0 0.5
0 1 0.0 0.5 0.0
1 0 0.5 0.0 0.5
1 1 0.0 0.5 0.5
e

Although, I would point out that the Qt terminal doesn't quite layout of 
the pixels correctly.  The left column pixels are about 5% to 10% too 
wide and overlap the right column pixels.  The wxt terminal is better at 
this, but I notice that wxt has some problems when scaling the plot 
size.  Sometimes there is a small white space between the axes and image.

This sort of works:

reset
set offset 0.5, 0.5, 0.5, 0.5
set cbrange [0:1]
unset key
set tics out
plot '-' with rgbimage
0 0 0.0 0.0 0.5
0 1 0.0 0.5 0.0
1 0 0.5 0.0 0.5
1 1 0.0 0.5 0.5
e

but it seems to me that a 0.5 border is created, but then the autorange 
is taking that extra space to compute nice round numbers a little bigger 
than the 0.5 border, i.e., [-1:2].

We should come up with a definition for the image pixel coordinate 
system, if that hasn't already been done.  I'm recalling confusion about 
one of us thinking in terms of pixel centers, while the other in terms 
of pixels at the coordinate system leading edge.  They're both valid and 
the choice is somewhat arbitrary, but it would be nice to have the 
accepted spatial coordinate system written down so that when programming 
there's no doubt about how to program computations.  We should have:

1) A fairly detailed statement in a code file or a text file.

2) An intricate demo plotting an image along with some lines and arrow 
describing what the convention is.

Dan

Re: Proposal: Saving graphs from Qt and wxt terminals

[Jérôme L. <lod...@us...>]

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

Re: Proposal: Saving graphs from Qt and wxt terminals

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

> 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

Re: Proposal: Saving graphs from Qt and wxt terminals

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

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

Re: Proposal: Saving graphs from Qt and wxt terminals

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

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

Re: Simultaneous qt and wxt terms (was Re: Proposal: Saving graphs from Qt and wxt terminals)

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

On Saturday, 25 October 2014 01:25:51 PM Daniel J Sebald wrote:
> On 10/25/2014 01:05 PM, Bastian Märkisch wrote:
> > Am 25.10.2014 um 19:46 schrieb Daniel J Sebald:
> >> On 10/25/2014 03:40 AM, Daniel J Sebald wrote:
> >>
> >>> I removed the interlock test and it creates quite a mess with invalid
> >>> events, seg faults in bad library calls, to scratch the surface.
> >>>
> >>> Investigating a bit, I think the problem lies in the fact wxt terminal
> >>> is not in its own process.
> >>
> >> It's too much work to do this in an afternoon or so. Having looked at
> >> the code, though, I'd say some things get simplified when WXT is run in
> >> its own process as an outboard plotter. All these sorts of conditions
> >>
> >> #if defined(WXT_MONOTHREADED) || defined(_Windows)
> >>
> >> go away.
> >>
> >> Dan
> >
> > Btw. Timothée had been working on this years ago, see patch #380
> > https://sourceforge.net/p/gnuplot/patches/380
> 
> Thanks.  That could save a ton on the initial tedious work of putting 
> bulk of the code in its own program.
> 
> 
> > Also, the qt and wxt terminals run nicely in the same session on
> > Windows. It just took some effort to make qt->waitforinput() work.
> >
> > Since waitforinput() is a terminal routine it typically only handles
> > events from the library the current terminal uses. If we want to use
> > multiple libraries in the same process, we need to replace/extend that
> > mechanism.
> 
> I think once the active terminal is changed, mousing and keyboard input 
> is disabled for others.
> 
> 
> >  From my experience with the (outboard) qt terminal, I sincerely doubt
> > that moving the wxt terminal to its own process will significantly
> > simplify the source.
> 
> It won't simplify the source, but it will get rid of those "corner 
> cases".  As you point out, Windows works fine for both terminals...and 
> that's why the things like:
> 
> #if defined(WXT_MONOTHREADED) || defined(_Windows)

Before tearing into a project to split off wxt into a separate process
altogether, I think you should look into making the WXT_MONOTHREADED
variant work on linux.   Some/all of the problems it now has are due to
the graphics event loop running in a separate thread.

Anyhow, I really don't see the need for typical users to switch between
qt and wxt within a single gnuplot session.  Especially because the
distro-packaged gnuplot versions probably only provide one or the other,
not both.  It can be handy for a developer, yes, because you'd like to
compare the output of the two terminals.  But I don't think that's a
particularly useful thing for a typical gnuplot session.
So really I think this is low priority compared to some other issues.   

For instance, how about fixing the auto-scaling for image plots?
Right now the default behavior is to auto-scale to the center of
the 4 corner pixels, which clips all the outermost pixels in half.
That would be OK if there were an easy way to override it, but
many of the obvious commands don't work.
E.g.
	 set xrange [-0.5:*] 			# doesn't work with image data
     set offset .5, .5, .5, .5		# this doesn't work either


	Ethan 



> 
> are in the code.  But if WXT is running in its own thread all the 
> Windows items should still work fine as well as linux.  That's the idea 
> anyway.
> 
> Just to confirm, does the Qt terminal work in both Linux and Windows?
> 
> Dan
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Simultaneous qt and wxt terms (was Re: Proposal: Saving graphs from Qt and wxt terminals)

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

On 10/25/2014 01:05 PM, Bastian Märkisch wrote:
> Am 25.10.2014 um 19:46 schrieb Daniel J Sebald:
>> On 10/25/2014 03:40 AM, Daniel J Sebald wrote:
>>
>>> I removed the interlock test and it creates quite a mess with invalid
>>> events, seg faults in bad library calls, to scratch the surface.
>>>
>>> Investigating a bit, I think the problem lies in the fact wxt terminal
>>> is not in its own process.
>>
>> It's too much work to do this in an afternoon or so. Having looked at
>> the code, though, I'd say some things get simplified when WXT is run in
>> its own process as an outboard plotter. All these sorts of conditions
>>
>> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>>
>> go away.
>>
>> Dan
>
> Btw. Timothée had been working on this years ago, see patch #380
> https://sourceforge.net/p/gnuplot/patches/380

Thanks.  That could save a ton on the initial tedious work of putting 
bulk of the code in its own program.


> Also, the qt and wxt terminals run nicely in the same session on
> Windows. It just took some effort to make qt->waitforinput() work.
>
> Since waitforinput() is a terminal routine it typically only handles
> events from the library the current terminal uses. If we want to use
> multiple libraries in the same process, we need to replace/extend that
> mechanism.

I think once the active terminal is changed, mousing and keyboard input 
is disabled for others.


>  From my experience with the (outboard) qt terminal, I sincerely doubt
> that moving the wxt terminal to its own process will significantly
> simplify the source.

It won't simplify the source, but it will get rid of those "corner 
cases".  As you point out, Windows works fine for both terminals...and 
that's why the things like:

#if defined(WXT_MONOTHREADED) || defined(_Windows)

are in the code.  But if WXT is running in its own thread all the 
Windows items should still work fine as well as linux.  That's the idea 
anyway.

Just to confirm, does the Qt terminal work in both Linux and Windows?

Dan

Re: Simultaneous qt and wxt terms (was Re: Proposal: Saving graphs from Qt and wxt terminals)

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

Am 25.10.2014 um 19:46 schrieb Daniel J Sebald:
> On 10/25/2014 03:40 AM, Daniel J Sebald wrote:
>
>> I removed the interlock test and it creates quite a mess with invalid
>> events, seg faults in bad library calls, to scratch the surface.
>>
>> Investigating a bit, I think the problem lies in the fact wxt terminal
>> is not in its own process.
>
> It's too much work to do this in an afternoon or so.  Having looked at
> the code, though, I'd say some things get simplified when WXT is run in
> its own process as an outboard plotter.  All these sorts of conditions
>
> #if defined(WXT_MONOTHREADED) || defined(_Windows)
>
> go away.
>
> Dan

Btw. Timothée had been working on this years ago, see patch #380
https://sourceforge.net/p/gnuplot/patches/380

Also, the qt and wxt terminals run nicely in the same session on 
Windows. It just took some effort to make qt->waitforinput() work.

Since waitforinput() is a terminal routine it typically only handles 
events from the library the current terminal uses. If we want to use 
multiple libraries in the same process, we need to replace/extend that 
mechanism.

 From my experience with the (outboard) qt terminal, I sincerely doubt 
that moving the wxt terminal to its own process will significantly 
simplify the source.

   Bastian

Re: Simultaneous qt and wxt terms (was Re: Proposal: Saving graphs from Qt and wxt terminals)

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

On 10/25/2014 03:40 AM, Daniel J Sebald wrote:

> I removed the interlock test and it creates quite a mess with invalid
> events, seg faults in bad library calls, to scratch the surface.
>
> Investigating a bit, I think the problem lies in the fact wxt terminal
> is not in its own process.

It's too much work to do this in an afternoon or so.  Having looked at 
the code, though, I'd say some things get simplified when WXT is run in 
its own process as an outboard plotter.  All these sorts of conditions

#if defined(WXT_MONOTHREADED) || defined(_Windows)

go away.

Dan

Simultaneous qt and wxt terms (was Re: Proposal: Saving graphs from Qt and wxt terminals)

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

On 10/25/2014 12:54 AM, sfeam wrote:
> On Saturday, 25 October 2014 12:18:45 AM Daniel J Sebald wrote:
>
>>
>
>>  I notice that gnuplot doesn't allow wxt and Qt in the same session.
>
>>  What is the issue there? I see this:
>
>>
>
>>  /* The qt and wxt terminals cannot be used in the same session. */
>
>>  /* Whichever one is used first to plot, this locks out the other. */
>
>>  void *term_interlock = NULL;
>
> The wxt and qt libraries do not play nicely with each other.
>
> They trample on each other's memory allocation schemes.
>
> Or at least they did back when qt was first added to gnuplot.
>
> Rather than having the program die in strange ways from the
>
> memory conflict, it seemed better to only allow one or the
>
> other at a time.
>
> You could try removing the interlock test to see if the memory
>
> conflict is still there. I haven't gone back to check for a
>
> long time.

I removed the interlock test and it creates quite a mess with invalid 
events, seg faults in bad library calls, to scratch the surface.

Investigating a bit, I think the problem lies in the fact wxt terminal 
is not in its own process.  I notice in the PID list that there is 
gnuplot_qt and when resizing the Qt window, that process CPU consumption 
ramps up.  Now, when resizing the wxWidgets plot window it is the other 
"gnuplot" process for which CPU consumption ramps up.

Running two separate gnuplot processes, one running Qt term and the 
other running wxt term seems to have no problems.  This really isn't a 
surprise, as it just confirms that Qt and wxt can exist at the same time 
in the desktop space.

If I recall correctly, fork() is used to create a separate process for 
the Qt outboard plotter--thus Qt can do graphics in that new process 
with default main thread.  But under the scenario of both qt and wxt 
terminals active the problem is that there are two graphics entities in 
a main thread, which is probably bad.  For example:

launch gnuplot     -> PID_gnuplot created
plot into wxt term -> instantiate underlying graphics in PID_gnuplot
set term qt        -> fork PID_gnuplot process for which wxt graphics
                    -> is already active to create PID_gnuplot_qt
plot into qt term  -> instantiate underlying graphics for PID_gnuplot_qt

At that point PID_gnuplot_qt has two underlying graphics "kernels" (for 
lack of better understanding) in its main thread probably creating havoc 
at a real low level.

I think that wxt needs to be in its own process, i.e., an outboard 
plotter.  What about these other terminals that remain persistent?

"
  Many gnuplot terminals (aqua, pm, qt, x11, windows, wxt, ...)
  open separate display windows on the screen into which plots
  are drawn.  The `persist` option tells gnuplot to leave these
  windows open when the main program exits.
"

x11 is also outboard, so that should work fine with qt terminal, and I 
just confirmed it does.  But then again, it could simply be that x11 is 
very low level (doesn't use the file dialogs and whatever else).  Is 
there anyone who can run both aqua followed by qt, or does that have a 
similar clash of system resources?

I see that when exiting, that's when wxt_atexit() forks:

	if (openwindows > 0)
		pid = fork();
	else
		pid = -1;

	/* the parent just exits, the child keeps going */
	if (!pid) {

That works, but at the same time it's not really exiting the process, 
just giving the command line back to the terminal window.  The exact 
same process exists as a duplication.

Dan

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On 10/25/14 00:19, Ethan A Merritt wrote:
> 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?

Worth noting here that this is a different thing to reproducing what is 
on the screen in a file. The pdf case is drifting into a pdf replot via 
pdf term or a pseudo pdf term. This is the logical way to produce a pdf 
but is differing from reproducing what is on the screen.  It does fulfil 
Philipp's  ease of use objective but may not produce the same thing. As 
per the other terminal output differences.

This will presumably be subject to the usual font size and placement and 
line style irregularities.

This should be clearly documented otherwise users will not understand 
why, when they save the output, it looks different.

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

Almost the only argument for lossy jpeg is the compression ratio. 
However, on images with few colours and large blocks png comes pretty 
close and does not have ringing and edge distortions. I never use jpeg 
for graphs.

OTOH, gif has a substantial advantage for graphs which typically have a 
very low colour count and compresses block graphics very well and is 
lossless.

I don't use it much myself but it would not be hard to image web-based 
or embedded applications where producing a very compact version of a 
graph may be needed.

I use gnuplot actually running on an embedded system and retained just 
the SVG terminal because I needed to rescale the image and interactive 
mouse  for accurate readout in a scientific context. Size and bandwidth 
was not a key criterion on this very specific application. If the usage 
did not require these features I would have used gif.

Peter.


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

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

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

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On Saturday, 25 October 2014 12:18:45 AM Daniel J Sebald wrote:
> 
> I notice that gnuplot doesn't allow wxt and Qt in the same session. 
> What is the issue there?  I see this:
> 
> /* The qt and wxt terminals cannot be used in the same session. */
> /* Whichever one is used first to plot, this locks out the other. */
> void *term_interlock = NULL;

The wxt and qt libraries do not play nicely with each other.
They trample on each other's memory allocation schemes.
Or at least they did back when qt was first added to gnuplot.
Rather than having the program die in strange ways from the
memory conflict, it seemed better to only allow one or the
other at a time.

You could try removing the interlock test to see if the memory
conflict is still there.  I haven't gone back to check for a
long time.

	Ethan

> I suppose shutting down the existing external program with a terminal 
> change isn't the most graceful because it closes plot windows.  On the 
> other hand, neither is having to exit the program to switch the terminal 
> very elegant--plus doing so would close all existing windows, what is 
> apparently to be avoided.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> 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

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

On Saturday, 25 October 2014 12:01:57 AM Daniel J Sebald wrote:
> On 10/24/2014 05:04 PM, Ethan A Merritt wrote:
> > On Friday, 24 October, 2014 15:17:01 Daniel J Sebald wrote:
> >> 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.

Ah, I understand.
See Feature Request #314

The new aspect ratio isn't applied until the next replot.
The qt terminal has a tool widget to toggle whether you
want this to happen automatically.  The wxt should have one also.
Patches welcome.

	Ethan

Re: Proposal: Saving graphs from Qt and wxt terminals

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

On 10/24/2014 05:19 PM, Ethan A Merritt wrote:
> 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.

The color is working for me now.  I'm not sure what happened.  It could 
have been some bad interaction from me messing around with multiple 
terminals in the same session...


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

I doubt that one.  There would likely be complaints.


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

Build options are fine by me, given it is the interactive terminal in 
question.  But the default should still include all decent terminals.

I notice that gnuplot doesn't allow wxt and Qt in the same session. 
What is the issue there?  I see this:

/* The qt and wxt terminals cannot be used in the same session. */
/* Whichever one is used first to plot, this locks out the other. */
void *term_interlock = NULL;

I suppose shutting down the existing external program with a terminal 
change isn't the most graceful because it closes plot windows.  On the 
other hand, neither is having to exit the program to switch the terminal 
very elegant--plus doing so would close all existing windows, what is 
apparently to be avoided.

Dan