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

Re: postscript terminal bug?

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

Daniel J Sebald wrote:

> it to do so*.  Or somehow we creatively reference a palette somewhere 
> else in the document.  Not sure how to do that... maybe write a little 
> PostScript routine to "search for page #X and use its palette".

On second thought, this might be dodgy because if the file is sent to a printer, the palette on page 1 may be long gone when page 41 roles around.  So page 41 referencing page 1 would be dodgy.  The most surefire way to protect against devices with limited memory capacity would be to put the palette on each page.  Bloated file, but...

What does PDF do?  That seems to work and quite often is a compact file.  (Perhaps it is the compression that does that.)

Dan

Re: postscript terminal bug?

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

Ethan Merritt wrote:
> On Friday 09 June 2006 01:31 am, Daniel J Sebald wrote:
> 
>>The last demo of 'pm3d.dem', the one showing the grid point options,
>>doesn't appear to work correctly with the postscript terminal.  The
>>demo works fine in PDF.  
> 
> 
> Confirmed.
> 
> There is a missing "gsave" in the output, at the location where
> there used to be a palette reload sequence.  This makes me suspect
> the change from 2006-03-18 that removed this reload sequence
> if the palette was unchanged.
> 
> ...yup.
> This one line reversion makes the problem go away.
> That doesn't mean it is the correct fix, of course, but it 
> confirms the origin of the problem:
> 
> Can you look into this, Dan?
> I think you were the one who suggested that optimization originally.

Good memory...  Well, I've confirmed a solution.  There are extra grestore's in the PostScript code.  Attached is a patch showing which code simply need be deleted from graph3d.c.  Reading the message that was left there, it sounds as though this code isn't necessary, at least in the current set up.  (If it isn't needed, one wonders if the terminal entry can be removed altogether.)

I say "current set up" because there is still a significant problem.  I think our logic for not writing the palette so often is correct.  However, this is still the element of these workings in which the terminal should retain the palette in case it personally needs it again.

Here's the problem.  I'm paging through the output of 'pm3d.dem', call it 'pm3d.ps', for the postscript terminal.  If I linearly step from page 1 through page 41 the palette is correct.  However, if I jump about, the palette is not correct.  Say I go to the page with the bowl shaped gray scale, then start stepping backward.  The pages that had a color palette now have a gray palette until a page is reached where the palette has changed.

Now, PDF output, call it 'pm3d.dem' works fine.  I suspect that internally, the PDF driver keeps a record of the palette the programmer last sent it and knows to put a copy of the palette in for each page.  (Or somehow define the palettes up front and put a reference in for each page so that the palette can be saught.)

So what would be your strategy for this?  My suggestion is for the PostScript terminal driver to keep a record of the palette sent to it whenever the core code sends a new palette.  (I think all of the code is present for easily making a copy.)  Then for each new page, the terminal code puts a copy of the palette in place *without the core code telling it to do so*.  Or somehow we creatively reference a palette somewhere else in the document.  Not sure how to do that... maybe write a little PostScript routine to "search for page #X and use its palette".

Dan

Re: postscript terminal bug?

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

On Friday 09 June 2006 01:31 am, Daniel J Sebald wrote:
> The last demo of 'pm3d.dem', the one showing the grid point options,
> doesn't appear to work correctly with the postscript terminal.  The
> demo works fine in PDF.  

Confirmed.

There is a missing "gsave" in the output, at the location where
there used to be a palette reload sequence.  This makes me suspect
the change from 2006-03-18 that removed this reload sequence
if the palette was unchanged.

...yup.
This one line reversion makes the problem go away.
That doesn't mean it is the correct fix, of course, but it 
confirms the origin of the problem:

Can you look into this, Dan?
I think you were the one who suggested that optimization originally.

--- gnuplot/src/color.c 2006-06-09 11:04:52.000000000 -0700
+++ gnuplot-cvs/src/color.c     2006-06-09 11:05:07.000000000 -0700
@@ -120,7 +120,7 @@
           passed there to create the header or force its initialization
         */
 
-       if (memcmp(&prev_palette, &sm_palette, sizeof(t_sm_palette))) {
+       if (1) {
            term->make_palette(&sm_palette);
            prev_palette = sm_palette;
            FPRINTF(("make_palette: calling term->make_palette for term with ncolors == 0\n"));



-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

postscript terminal bug?

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

The last demo of 'pm3d.dem', the one showing the grid point options, doesn't appear to work correctly with the postscript terminal.  The demo works fine in PDF.  Known bug?  (I know there were some emails on the list recently about postscript.)

Dan

Re: enable GNU readline by default?

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

Timoth=E9e Lecomte wrote:

> I would prefer the opposite reasoning : gnuplot is distributed mainly i=
n=20
> binary form by distributions. To avoid them legal issues (even if it is=
=20
> likely that nobody will complain in a court), it is better to default t=
o=20
> the choice that legally works in any situation. I am sure a packager=20
> prefers working on a program that does require a minimum of customizati=
on.
>=20
> How many users are really compiling gnuplot from source regularly ?=20

Probably a lot; because it is so easy and fast to compile.


> I like Bastian's idea to use a BSD-licensed equivalent, if it is=20
> maintained and broadly available. Otherwise it is gnuplot's license tha=
t=20
> needs some more attention. It is a matter of honesty.

Well, the license thing we've talked about at length.  I still don't see =
why so many people put so much effort into programming gnuplot, yet the l=
icense issue gets little attention.

Dan

Re: [Fwd: Re: gnuplot 4.1 and imagesc]

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

> how do I get Octave to use the new image features in gnuplot 4.1?

Get imagegp.m from
 	http://gnuplot.sourceforge.net/links.html

> would like get imagesc to respect "subplot" and "print". Is this
> possible?

It would have to be organized on octave's side (cache all the command to 
reproduce a drawing). It's not a problem of imagesc or gnuplot; just gnuplot 
has never provided "replot of multiplot".

---
PM

What's left for a 4.2 release?

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

On Wednesday 07 June 2006 09:31 pm, Timoth=E9e Lecomte wrote:
> Here is a message from the octave mailing list kindly asking for a
> gnuplot release mainly for the image code.
> Any update on the remaining work, compared to Ethan's previous review?

Update 8 June 2006
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

So far as I am concerned, there are 4-5 patches highlighted below
that should go into CVS more or less immediately, at which point we
can freeze the codebase for a 4.1 release.  But it's not my call.


I'm not going to include a full rundown of every outstanding entry
on SourceForge, since most have not changed.  Here's a brief
summary:


=46eature Requests
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Two new ones since my original posting.
#1117724 should be trivial once we have the GPVAL_* scheme
of user variables. The others are hardly critical
  #1486690  	   timefmt does not support fractions of seconds
  #1480115   	  images with transparency in plot
  #1376595         Class and name strings of X Window
=3D>#1117724         [fit] access to resulting chisquare
  #1078852         Flexible use of geographic coordinates (ex. DD:MM:SS)
  #674055          mouse coordinate read-out in multiplot mode


Core code
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>Known bugs:
>
>- Clipping, particularly of arrows and filled polygons, is still
>  not done cleanly and some terminals crash on reasonable input. =20
>  This is the only known bug that I consider release-critical.

   Now fixed (so far as I know) except for external library errors
   (gd, pdf) and possible some corner cases of large symbols drawn
   very near the edge of the plot.  I don't have an example of this,
   but it seems to me that the core code does not protect against it.

> - Treatment of "missing" data as opposed to "invalid" data.
>   I think this is more a matter of poor documentation than an actual
>   bug, but I could be wrong.  In any event, it's not fixable until
>   someone can point to an unambiguous statement of what *should*
>   happen in both cases, and a reproducible example that doesn't act
>   that way. SF bugs #775810 #918793 #969322 #1403945

   No change

> - Miscellaneous open bug reports on SourceForge
>    #1408955        ytics have wrong date with ydata time and "using 2"
>    #1363641        dgrid3d / xrange interaction
>    #1158281        plotting a ternary function with undefined values
>    #1107709        plot [-1:1] x is plotted with asymmetric y-axis
>    #1042785        reversed axis range breaks filled curves
>    #1039309        Strange xtics on 'time' plot
>    #1004754        Tics and grid slightly outside border.
>     #992528        `set offset` can break `with filledcurves`
>     #634506        plotting a subrange of a contour plot

    No change. Nothing here is critical

Patchsets
=3D=3D=3D=3D=3D=3D=3D=3D=3D

Nothing left on my original "must-do" list.
A few still may still be open for discussion.

>  #1218873         Change text rotating angle from int to float
    Hans-Bernhard doesn't like this one, so I've dropped it from=20
    the list
>  #1244775         Isolines optional on datafile splots
>  #1199186         strftime and strptime
>  #1077726         true depth ordering for pm3d plots
    These remain on my "OK, but only if someone else does the work"
    list

New ones added since the original list. The ones below should go
into CVS as soon as possible

=3D>   #1488448  	  User-available GPVAL_ variables
=3D>   #1461275  	  Japanese translation of faq.tex
=3D>   #1460418     Japanese Manuals
=3D>   #1497957  	  make built-in function defined() match docs

   These two also sound reasonable, but I haven't really looked at
   them in detail so I don't have an opinion

   #1499728  	  revamped stat.inc
   #1445064  	  Gnuplot fitting improvements

Drivers
=3D=3D=3D=3D=3D=3D=3D

wxt is in CVS and working.  Some things could be polished or
extended, but I have no trouble with releasing it as-is.

We've been trading patches and proposals back and forth
about hot-key processing (<space> and <q> typed into an
interactive plot window).  But I don't think this issue is
release-critical.

There are two contributions of preliminary new drivers:
   #1398474  	  a driver for GD.pm
   #1463191  	  First port.trm
And Email but no actual patchsets from Mojca Miklavec=20
<moj...@gm...> requesting inclusion of
another TeX variant.  I have seen no discussion or feedback
on any of these, so I have no idea how well they work or if
they are worth polishing for inclusion in CVS.  But they are
IMHO, not release-critical.

>> forwarded from Octave list
> I am very interested in this, but this is where I'm a little
> frustrated with gnuplot's slow release cycles. I would be willing to
> work on patches for octave, but I wouldn't expect John to apply
> patches until a 4.1 release is widely available in the distributions,
> and I don't really want to maintain patches to a source tree that
> will be changing in the meantime. Do any of the gnuplot insiders on
> the list here know how soon we might expect a release?
>
> Quentin

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: [Fwd: Re: gnuplot 4.1 and imagesc]

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

Timoth=E9e Lecomte wrote:
> Here is a message from the octave mailing list kindly asking for a=20
> gnuplot release mainly for the image code.
> Any update on the remaining work, compared to Ethan's previous review ?=
=20
> Any domain where I could help, apart from stabilizing the wxWidgets=20
> terminal ?

Pick a bug in the list, I guess.  They seem to be coming in at a higher r=
ate lately... probably reflects increased usage.

Should keep a list of things to do on the gnuplot.info page.  In any case=
 I'll lobby for the following before a 4.2 release:

1)  BUG 1488168  	  z_floor and z_ceiling based on xyplane.absolute

There is a patch there to fix that one.  After applying this patch I sugg=
est also a change to the mouse behavior for the scale.  Have the xyplane =
move in the direction the mouse moves (i.e., invert the scale movement) a=
nd also have the motion be linear and not tend to zero as the xyplane nea=
rs zero.  If Ethan doesn't have time to change that and thinks it is wort=
h changing, I can modify that.

2)  BUG 1503114  	  FIX: 1107709 plot [-1:1] x is plotted with asymmetric=
 y-axis

I picked a bug in the list and fixed it.  It is a short little patch that=
 puts a 0.01 tolerance in computation of the tics before doing ceil() or =
floor().  That means an overrun of 1/100 of a tic will be ignored.  Not a=
 problem in most cases and if the user is concerned or even notices, manu=
al ranging can be done.

3)  PATCH 1494573  	  check number of variables for u.d. functions

This is a really nice patch that will verify that the number of variables=
 supplied to a defined function matches the number of variables when defi=
ned.  Pretty straightforward patch; it simply adds a record to the struct=
ure of the number of variables.

4)  PATCH 1499728  	  revamped stat.inc

Crosses the t's and dots the i's on the p.d.f./c.d.f. definitions in stat=
.inc.  Also adds a bit of variety to 'prob.dem' making it more tutorial i=
n fashion.

5)  PATCH 1027032  	  Connect gnuplot_x11 to exterior application window

This one is of no urgency to me, but someone at some point requested it. =
 We're close on this one, and there was some detail left uncovered I can'=
t recall right now.  But it would be nice to add this one just to get it =
out of the patch list.

Dan

Re: enable GNU readline by default?

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

Timoth=E9e Lecomte wrote:
> I like Bastian's idea to use a BSD-licensed equivalent, if it is=20
> maintained and broadly available. Otherwise it is gnuplot's license tha=
t=20
> needs some more attention. It is a matter of honesty.

The discussion about readline/libedit has come up in the past already - s=
ee e.g.
http://search.gmane.org/?query=3Dlibedit&group=3Dgmane.comp.graphics.gnup=
lot.devel
- so it wasn't my idea. But it has been on my todo-list for a while now. =
;-)

I did a quick and dirty test if gnuplot/libedit may be compiled using
cygwin. Here're some observations:

command.c (restore_prompt()):
	rl_forced_update_display() is not supported by libedit
gp_hist.h:
	have to include <editline/readline.h> instead of <readline/history.h>
history.c (write_history_list()):
	history_list() is not supported by libedit
mouse.c (alert()):
	rl_ding() is not supported by libedit
plot.c:
	have to include <editline/readline.h> instead of <readline/tilde.h>
	variable rl_complete_with_tilde_expansion is not available (main())
readline.h:
	include <editline/readline.h> instead of <readline/readline.h>


Most of the changes needed to get it compiling are really minor.
But there're some problems:
* The missing rl_forced_update_display() causes some text display problem=
s.
* It is not clear (to me) if the lack of rl_complete_with_tilde_expansion=
 is one
* write_history_list() has to be rewritten using the available functions
* some of the functions in libedit are stubs only and I haven't checked i=
f
   gnuplot uses any of these (see editline/readline.h)
* on my box not all keys worked as expected (might be a configuration pro=
blem
   on my side though)

Bastian

Re: enable GNU readline by default?

[<tim...@en...>]

Ethan Merritt wrote:
> On Thursday 08 June 2006 12:58 am, Petr Mikulik wrote:
>  =20
>>>> Now: What about enabling GNU readline by default as well?
>>>>        =20
>>> I agree that it would save work but the answer is no for the moment
>>> because of the licence incompatibility.
>>>      =20
>> There is no problem with the license until you distribute the binary.
>> Which normal users don't.
>>    =20
>
> That is correct.  It seems reasonable to me that ./configure=20
> can just test for gnu readline and include it unless explicitly
> disabled by the person doint the build.  Normal users building
> from source have no license issues.  Distributions can make their
> own call about  whether they feel constrained by the license
> and want to instead use the built-in via=20
>    ./configure --with-readline
> Last I checked, about half of the distros did and the other
> half didn't
>  =20
I would prefer the opposite reasoning : gnuplot is distributed mainly in=20
binary form by distributions. To avoid them legal issues (even if it is=20
likely that nobody will complain in a court), it is better to default to=20
the choice that legally works in any situation. I am sure a packager=20
prefers working on a program that does require a minimum of customization.

How many users are really compiling gnuplot from source regularly ?=20
Sourceforge says there are more than 10000 downloads per months for=20
gnuplot-4.0 , but I am pretty sure most of them are downloads of the=20
Windows binary version.

Others, like me,  probably add "--prefix=3D/home/user" or something like=20
that each time they compile gnuplot, and "--with-readline=3Dgnu" takes=20
just a few more milliseconds. "--enable-history-file" is a different=20
issue : it is about enabling a worthwhile feature that has absolutely no=20
objection.

I like Bastian's idea to use a BSD-licensed equivalent, if it is=20
maintained and broadly available. Otherwise it is gnuplot's license that=20
needs some more attention. It is a matter of honesty.

Best regards,

Timoth=E9e

Re: enable GNU readline by default?

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

On Thursday 08 June 2006 12:58 am, Petr Mikulik wrote:
> >> Now: What about enabling GNU readline by default as well?
> >
> > I agree that it would save work but the answer is no for the moment
> > because of the licence incompatibility.
>
> There is no problem with the license until you distribute the binary.
> Which normal users don't.

That is correct.  It seems reasonable to me that ./configure 
can just test for gnu readline and include it unless explicitly
disabled by the person doint the build.  Normal users building
from source have no license issues.  Distributions can make their
own call about  whether they feel constrained by the license
and want to instead use the built-in via 
   ./configure --with-readline
Last I checked, about half of the distros did and the other
half didn't

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: enable GNU readline by default?

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

As a side note: an autoconf'd version of libedit is available at
http://www.thrysoee.dk/editline/

It has a BSD style license and is actively maintained. The last
time I tried (~1yr ago) it required very little work to replace
GNU readline in gnuplot.
Right now I do not have the time to work on it though.

Petr Mikulik wrote:
>>> Now: What about enabling GNU readline by default as well?
>>>
>> I agree that it would save work but the answer is no for the moment be=
cause=20
>> of the licence incompatibility.
>=20
> There is no problem with the license until you distribute the binary. W=
hich=20
> normal users don't.
--=20
Bastian M=E4rkisch
Physikalisches Institut, Universit=E4t Heidelberg

Re: enable GNU readline by default?

[Juergen W. <wie...@fr...>]

Petr Mikulik wrote:
> > Yet another proposal, while in it: the bash also has a feature of
> > incremental search within the history with C-r.  AFAICS, this is
> > enabled by default in GNU readline.  Can this easily be enabled
> > while using the alternative interface to the readline library?  I
> > think this would be very convenient.
>
> You mean gnuplot's readline? If someone wants to implement it...

No, I meant the GNU readline interface. Ooops, forget about my post,
it actually is implemented. :-)  I was using the builtin readline
because I was too careless...  My fault, but thanks.

Juergen

Re: enable GNU readline by default?

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

>> Now: What about enabling GNU readline by default as well?
>> 
> I agree that it would save work but the answer is no for the moment because 
> of the licence incompatibility.

There is no problem with the license until you distribute the binary. Which 
normal users don't.

---
PM

Re: enable GNU readline by default?

[<tim...@en...>]

Petr Mikulik wrote:
> Enabling history file by default:
>
>  =20
>> No, I was thinking the same thing a few days ago, tired of having to a=
dd=20
>> --enable-history-file for each ./configure
>>    =20
>
> Ok, so history file has been enabled by default.
>
>
> Now: What about enabling GNU readline by default as well?
>
> It would save ordinary people to think about adding --with-readline=3Dg=
nu ...=20
> while gnuplot binary package distributors can do whatever they think is=
=20
> legal. This readline has now more features then gnuplot's readline.
>  =20
I agree that it would save work but the answer is no for the moment=20
because of the licence incompatibility.
Let's discuss the licence at the time of the next release with the=20
copyright owners, as concluded in a discussion on this list a few months=20
ago.

Timoth=E9e

Re: enable GNU readline by default?

[V. <gae...@no...>]

On Thu, Jun 08, 2006 at 09:26:50AM +0200, Petr Mikulik wrote:

> Now: What about enabling GNU readline by default as well?

    Yes !!

    Ga=EBl

PS : sorry Peter for the dup. , I hadn't seen I was reply to you only.

enable GNU readline by default?

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

Enabling history file by default:

> No, I was thinking the same thing a few days ago, tired of having to add 
> --enable-history-file for each ./configure

Ok, so history file has been enabled by default.


Now: What about enabling GNU readline by default as well?

It would save ordinary people to think about adding --with-readline=gnu ... 
while gnuplot binary package distributors can do whatever they think is 
legal. This readline has now more features then gnuplot's readline.


> Yet another proposal, while in it: the bash also has a feature of
> incremental search within the history with C-r.  AFAICS, this is
> enabled by default in GNU readline.  Can this easily be enabled
> while using the alternative interface to the readline library?  I
> think this would be very convenient.

You mean gnuplot's readline? If someone wants to implement it...

---
PM

[Fwd: Re: gnuplot 4.1 and imagesc]

[<tim...@en...>]

Here is a message from the octave mailing list kindly asking for a=20
gnuplot release mainly for the image code.
Any update on the remaining work, compared to Ethan's previous review ?=20
Any domain where I could help, apart from stabilizing the wxWidgets=20
terminal ?

Best regards,

Timoth=E9e Lecomte


-------- Original Message --------
Subject: 	Re: gnuplot 4.1 and imagesc
Date: 	Wed, 07 Jun 2006 22:06:42 -0500
From: 	Quentin Spencer <qsp...@ie...>
To: 	Peter S=F8ndergaard <pe...@so...>
CC: 	octave <he...@oc...>
References: 	<114...@ka...>


Peter S=F8ndergaard wrote:

>Dear list,
>
>how do I get Octave to use the new image features in gnuplot 4.1? I
>would like get imagesc to respect "subplot" and "print". Is this
>possible?
>
>I am running Octave 2.9.5 (Fedora Core 5), but I have no problem in
>patching/upgrading.

I am very interested in this, but this is where I'm a little frustrated=20
with gnuplot's slow release cycles. I would be willing to work on=20
patches for octave, but I wouldn't expect John to apply patches until a=20
4.1 release is widely available in the distributions, and I don't really=20
want to maintain patches to a source tree that will be changing in the=20
meantime. Do any of the gnuplot insiders on the list here know how soon=20
we might expect a release?

Quentin

Re: wxWidgets terminal : XPM cursors and icons

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

> As you can see, hitting 'replot' is just what you want.
> only a full 'replot'-based solution is satifactory

I see. Then it's OK with me.

> adding a message somewhere (in the status bar probably) that hitting 
> 'replot' will fill the window.

Good idea, sth like "note: need replot to ..."


BTW: if I resize the x11 graph window so that it is small, the font sizes 
are still the same. However, the distance between x-axis and x-tic values 
(same for y-) is very narrow and even they overlap. The wxt terminal works 
properly. What's the problem with x11?

---
PM

Re: wxWidgets terminal : XPM cursors and icons

[<tim...@en...>]

Ethan A Merritt wrote:
> On Wednesday 07 June 2006 12:01 am, you wrote:
>  =20
>>>  =20
>>>      =20
>> Let's discuss on a practical case, and on a specific aspect of the=20
>> problem : the fonts scaling (the aspect ratio behaviour is related, if=
 I=20
>> give up on fonts, I will give up on the aspect ratio immediately).
>> I loaded multiplt.dem on both wxt and x11 with their default sizes whi=
ch=20
>> are in the order of 600x400, and then resized both windows to make the=
m=20
>> smaller.
>> Attached is the final screenshot. I honestly prefer the wxt output, ev=
en=20
>> if none of them are really readable.
>>    =20
>
> But you are focusing on the size (big/small) rather than the aspect
> ratio.  Most of the time if I want to resize a window it is to spread o=
ut
> the plot either horizontally or vertically.  The whole point  of
> the exercise is to change the aspect ratio.  Making it bigger or smalle=
r
> is just a side effect.  I really don't care much about the fonts in
> such a case.
>
> Example:
> The 4th plot of 'histograms.dem' works much better if the
> plot is taller than it is wide.  If I step through the demo in x11
> I can just drag the bottom edge of the window down and it spreads
> itself out nicely.  Dragging the bottom edge of the wxt window
> down accomplishes exactly nothing, at least not without a subseqent
> replot command.
>
> The more common case for me is examining plots of a time-series.
> I have standard scripts, but the length of time covered by the data
> can vary. I load the script and a plot pops up; if it corresponds
> to a long run, then I immediately want to stretch it in the horizontal
> in order to separate closely space features in the plot. This works
> quite naturally (to me) in x11, but again accomplishes nothing in the
> wxt terminal unless I explicitly replot after stretching the window. =20
>
> My thinking is that if the user changes the size/shape of the window,
> it is because he wants the plot to be that size/shape.  Making the
> pure horizontal or pure vertical stretch operations be effectively
> no-ops seems a strange choice.
>  =20
Your example are convincing. And the statement that the terminal should=20
follow the user's change makes sense. But to my mind, only a full=20
'replot'-based solution is satifactory, otherwise resizing doesn't=20
respect 'set size ratio -1' for example.
I am coming to the conclusion that it's not really a big deal, that it=20
can be solved later and definitely by hacking on 'replot'.
What I can do to make the behaviour more understandable is to make the=20
window background gray, maybe adding a message somewhere (in the status=20
bar probably) that hitting 'replot' will fill the window.

Timoth=C3=A9e

Re: wxWidgets terminal : XPM cursors and icons

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

On Wednesday 07 June 2006 12:01 am, you wrote:
> >   
> Let's discuss on a practical case, and on a specific aspect of the 
> problem : the fonts scaling (the aspect ratio behaviour is related, if I 
> give up on fonts, I will give up on the aspect ratio immediately).
> I loaded multiplt.dem on both wxt and x11 with their default sizes which 
> are in the order of 600x400, and then resized both windows to make them 
> smaller.
> Attached is the final screenshot. I honestly prefer the wxt output, even 
> if none of them are really readable.

But you are focusing on the size (big/small) rather than the aspect
ratio.  Most of the time if I want to resize a window it is to spread out
the plot either horizontally or vertically.  The whole point  of
the exercise is to change the aspect ratio.  Making it bigger or smaller
is just a side effect.  I really don't care much about the fonts in
such a case.

Example:
The 4th plot of 'histograms.dem' works much better if the
plot is taller than it is wide.  If I step through the demo in x11
I can just drag the bottom edge of the window down and it spreads
itself out nicely.  Dragging the bottom edge of the wxt window
down accomplishes exactly nothing, at least not without a subseqent
replot command.

The more common case for me is examining plots of a time-series.
I have standard scripts, but the length of time covered by the data
can vary. I load the script and a plot pops up; if it corresponds
to a long run, then I immediately want to stretch it in the horizontal
in order to separate closely space features in the plot. This works
quite naturally (to me) in x11, but again accomplishes nothing in the
wxt terminal unless I explicitly replot after stretching the window.  

My thinking is that if the user changes the size/shape of the window,
it is because he wants the plot to be that size/shape.  Making the
pure horizontal or pure vertical stretch operations be effectively
no-ops seems a strange choice.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxWidgets terminal : XPM cursors and icons

[<tim...@en...>]

Petr Mikulik wrote:
>> Let's discuss on a practical case, and on a specific aspect of the
>> problem : the fonts scaling (the aspect ratio behaviour is related, if=
 I
>> give up on fonts, I will give up on the aspect ratio immediately).
>> I loaded multiplt.dem on both wxt and x11 with their default sizes whi=
ch
>> are in the order of 600x400, and then resized both windows to make the=
m
>> smaller.
>> Here is the final screenshot : http://tipote.free.fr/resize.png
>> I honestly prefer the wxt output, even if none of them are really=20
>> readable.
>
> What about adding an check icon to the menu to switch on/off font=20
> scaling?
> (Switching off would help to adjust font sizes before output to png or=20
> ps, for example.)
>
Again, I think there's a confusion here : just hit 'replot' and it will=20
use the default font size.
To explain that in picture : http://tipote.free.fr/resize2.png

window 0 : 'plot x' at the default window size
window 1 : 'plot x' at the default window size, downsized, and 'replot'
window 2 : 'plot x' at the default window size, downsized

As you can see, hitting 'replot' is just what you want.

Timoth=E9e

Re: wxWidgets terminal : XPM cursors and icons

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

> Let's discuss on a practical case, and on a specific aspect of the
> problem : the fonts scaling (the aspect ratio behaviour is related, if I
> give up on fonts, I will give up on the aspect ratio immediately).
> I loaded multiplt.dem on both wxt and x11 with their default sizes which
> are in the order of 600x400, and then resized both windows to make them
> smaller.
> Here is the final screenshot : http://tipote.free.fr/resize.png
> I honestly prefer the wxt output, even if none of them are really readable.

What about adding an check icon to the menu to switch on/off font scaling?
(Switching off would help to adjust font sizes before output to png or ps, 
for example.)

---
PM

Re: wxWidgets terminal : XPM cursors and icons

[<tim...@en...>]

Ethan A Merritt wrote:
> On Tuesday 06 June 2006 04:08 pm, Timoth=E9e Lecomte wrote:
>  =20
>> Ethan Merritt wrote:
>>    =20
>>> I would rather the plot filled the window.
>>>      =20
>
>  =20
>> gnuplot> plot x    =3D> the plot window is filled, let's say it is 600=
x400
>> [you resize the window to 200x200]   =3D> the plot will be scaled to=20
>> 200x133, (font sizes and linewidths rescaled)
>> gnuplot> plot x    =3D> the plot window is filled again, the plot is=20
>> 200x200, the font sizes and linewidths are back to original.
>>
>> I like this behaviour because gnuplot has carefully taken the font siz=
es=20
>> into account to draw something with a good layout, so this layout shou=
ld=20
>> not be messed up when you resize your window (remember that we can't=20
>> call 'replot' automatically as it is not compatible with multiplot).
>>    =20
>
> X11 manages to resize multiplots just fine, so it's not impossible.
>  =20
Well, it does, but not by calling 'replot', which should be the ultimate
solution.
> Even if resizing a wxt window works slightly differently for multiplots=
,
> I would still rather have the plot continually redrawn to fill the plot
> area as the window is resized in the normal case.
>  =20
Let's discuss on a practical case, and on a specific aspect of the
problem : the fonts scaling (the aspect ratio behaviour is related, if I
give up on fonts, I will give up on the aspect ratio immediately).
I loaded multiplt.dem on both wxt and x11 with their default sizes which
are in the order of 600x400, and then resized both windows to make them
smaller.
Here is the final screenshot : http://tipote.free.fr/resize.png
I honestly prefer the wxt output, even if none of them are really readabl=
e.

Timoth=E9e

Re: wxWidgets terminal : XPM cursors and icons

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

On Tuesday 06 June 2006 04:08 pm, Timoth=E9e Lecomte wrote:
> Ethan Merritt wrote:
> > I would rather the plot filled the window.

> gnuplot> plot x    =3D> the plot window is filled, let's say it is 600x400
> [you resize the window to 200x200]   =3D> the plot will be scaled to=20
> 200x133, (font sizes and linewidths rescaled)
> gnuplot> plot x    =3D> the plot window is filled again, the plot is=20
> 200x200, the font sizes and linewidths are back to original.
>=20
> I like this behaviour because gnuplot has carefully taken the font sizes=
=20
> into account to draw something with a good layout, so this layout should=
=20
> not be messed up when you resize your window (remember that we can't=20
> call 'replot' automatically as it is not compatible with multiplot).

X11 manages to resize multiplots just fine, so it's not impossible.

Even if resizing a wxt window works slightly differently for multiplots,
I would still rather have the plot continually redrawn to fill the plot
area as the window is resized in the normal case.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742