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

Re: pslatex terminal output--Problem identified.

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

>> This is already supported in 4.1 via the "set termoption" command.
>> "set termoption enhanced" will flip the current terminal into
>> enhanced mode without changing anything else.
>> 
>> As of now only a limited subset of the possible terminal options
>> can be changed mid-flight in this way: {no}enhanced and the
>> default font.  Other options may be added, subject to the
>> concern that the option must have the same meaning for multiple
>> terminals.
>> 
>
> I guess I am not being clear. As I said, the problem with sticky options
> is that it is impossible to predict what setting one going to get when
> issued a command "set term post color". Let's say I am using a gnuplot
> as a graphical backend to some program and I want to have a command "print" 
> that does "set term post color; set output 'file.out'; replot".
> The only way I can get a consistent format of the output graph if I specify 
> explicitly _all_ the options to the "set term postscript" thing.

In summary, there are cases where modifiable options are preferred, and 
other where sticky options would be preferred.

Possible solutions:
- "set term{options} {no}stickyoptions"
- set term {xxx} default  or   reset term   or  unset termoptions

This would require an update to terminals. IMHO, it would be quite easy.

I propose this:
change
    TERM_PUBLIC void XXX_options __PROTO((void));
to
    TERM_PUBLIC void XXX_options __PROTO((int flag));

and if (flag==0) execute the current code, and if (flag==1) then reset all 
options to default values.

It needs to a small update to all terminals, but is easy to do.

> One example is when one does "set term post eps" and later "set term 
> pslatex". Since the "eps" option is sticky it messes up the pslatex 
> terminal...

Options are particular for a given terminal, not for different terminals. So 
the above case won't happen.

---
PM

Re: Suggestions needed for a new command

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

On Saturday 01 October 2005 03:46 pm, Petr Mikulik wrote:
>
> Maybe
>  	set ticslevel at 0

How could I miss the obvious?
(added to CVS).


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

Re: pslatex terminal output--Problem identified.

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

No, there is no bug. And it has nothing to do with "set term pop|push".

According to "help set terminal":

  Several terminals have many additional options.  For example, see `png`,
  or `postscript`.
  The options used by a previous invocation `set term <term> <options>` of a
  given `<term>` are remembered, thus subsequent `set term <term>` does
  not reset them.  This helps in printing, for instance, when switching
  among different terminals---previous options don't have to be repeated.

Thus with
  set term post eps
  show term
  set term post
  show term

it will stay with eps options.

For postscript terminal, use "set term default" to reset to default values. 
(However, this option is not available for other terminals.)

> FYI
>> From the octave list:
>
> Sincerely,
>
> Dmitri.
>
> ---------- Forwarded message ----------
> From: John W. Eaton <jw...@be...>
> Date: Sep 21, 2005 8:24 PM
> Subject: Re: pslatex terminal output--Problem identified.
> To: Pete Gustafson <wat...@ya...>
> Cc: he...@oc...
>
> OK, I think this might be a bug in gnuplot.  You can reproduce it with
> the following commands (these are essentially the commands that Octave
> is sending to gnuplot, but plotting a function instead of a data file
> to simplify things a bit)):
>
>  plot sin(x) title "line 1"
>  set terminal push
>  set term postscript eps enhanced color solid
>  set output "foo.eps"
>  replot
>  set terminal pop
>  set output
>  replot
>  set term pslatex
>  set output "foo.tex"
>  replot
>  quit
>
> I have not looked at the code, so I am only guessing here, but it
> seems that the problem might be that gnuplot is hanging on to some
> postscript terminal options even after the set terminal pop statement
> is executed.  If you insert something like
>
>  set term postscript landscape
>
> just after the set terminal pop statement, the problem goes away.  But
> how can Octave know that it should do that?  It seems it would be
> better for "set term pop" to restore the state of the terminal driver
> to whatever it was when "set term push" was executed.
>
> Here is a simpler example.  Compare foo.eps vs. foo.ps from the
> following two scripts.
>
> 1:
>  plot sin(x) title "line 1"
>  set terminal push
>  set term postscript
>  set output "foo.ps"
>  replot
>  set terminal pop
>  set output
>  replot
>  set term postscript eps enhanced color solid
>  set output "foo.eps"
>  replot
>  quit
>
> 2:
>  plot sin(x) title "line 1"
>  set terminal push
>  set term postscript eps enhanced color solid
>  set output "foo.eps"
>  replot
>  set terminal pop
>  set output
>  replot
>  set term postscript
>  set output "foo.ps"
>  replot
>  quit
>
> Looking at these I would expect foo.ps in both cases to be the simple
> full page postscript plot.  But in the second case, both plots are
> small eps style plots.
>
> I just checked the latest CVS gnuplot and it seems the behavior is the
> same.  Would someone like to report this problem and find out if it is
> intentional behavior or a bug?
>
> Thanks,
>
> jwe

Re: patch MAX_NUM_VAR in version 4.0.0

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

On Sat, 17 Sep 2005, Petr Mikulik wrote:

>> # define MAX_NUM_VAR    5
>> 
>> in 'syscfg.h' e.g. to:
>> 
>> # define MAX_NUM_VAR   10
>
> I vote for this change .. maybe even to 12 (i.e., 4 vectors)?

No answer, thus agreed to set the default to 12?

---
PM

Re: Suggestions needed for a new command

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

> 	set zzeroaxis      <== new command
> 	set ticslevel YMIN/(YMAX-YMIN)       <== problematic
>
> Possibilities include
>
> 	set view axes
> 	set zeroaxis {something}
> 	set axes {<linetype>}
>
> Other suggestions?

Maybe
 	set ticslevel at 0

--
PM

Re: pslatex terminal output--Problem identified.

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

> The sticky options may help with typing in a short  interactive
> session, but generally
> they are bad idea (in my opinion). E.g. you may have set some options
> at the beginning of the session and later you want some different options.
> Since you may have forgotten which options you did modify
> the only sure way to get the desired options is to set terminal with
> _all_ options
> explicitly specified. What making thing worse is that "default" keyword
> apparently does not set all options to the default state but only some.
> Those problems become especially painful, when gnuplot is driven by an external
> program (e.g. octave). See this thread for one example:
>
> http://www.octave.org/octave-lists/archive/help-octave.2005/msg03471.html

You can reset "set" commands to the default values by the "reset" command. 
This works for all except for the "set terminal" command. There, a command 
like "set terminal reset" would be required (for the current terminal) or 
"reset terminals" (to reset all terminals). You are welcome to implement 
this feature.

IMHO, these permanent options are a good idea even for interactive driving: 
for example, you can set terminals to "enhanced" mode in your .gnuplot file 
and don't need to do this in the driving program.

---
PM

wxWidgets terminal gets multiple heads

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

Hi !

I have just uploaded a new version of my wxwidgets terminal on the
gnuplot's developpement pages.

http://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1267434&grou=
p_id=3D2055&atid=3D302055

It's really a major step towards stability, as I fixed most things that
were reported about the previous patch. In particular, annoying bugs
have disappeared, and the version now supports multiple plot windows,
with the usual command "set term wxt <n>". Here is a screenshot :

http://tipote.free.fr/wxt11.png

I hope someone can try and give some feedback.

Timoth=E9e Lecomte

Re: pslatex terminal output--Problem identified.

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

On Sunday 02 October 2005 12:02 pm, Dmitri A. Sergatskov wrote:
> One example is when one does "set term post eps" and later
> "set term pslatex". Since the "eps" option is sticky it messes up the
> pslatex terminal...

Are you sure?  That would indeed be a bug.
But it doesn't seem to be the case here when I try it.
I get identical output from the pslatex terminal whether or not
a previous plot has used "set term post eps".  If you can
reproduce your problem, please send a bug report and a script
that demonstrates the problem.

gnuplot> set term post eps
Terminal type set to 'postscript'
Options are 'eps noenhanced defaultplex \
   leveldefault monochrome colortext \
   dashed dashlength 1.0 linewidth 1.0 butt \
   palfuncparam 2000,0.003 \
   "Helvetica" 14 '
gnuplot> set term pslatex
Terminal type set to 'pslatex'
Options are 'rotate   leveldefault monochrome colortext \
   dashed dashlength 1.0 linewidth 1.0 butt \
   palfuncparam 2000,0.003 \
   rotate noauxfile '

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

Re: pslatex terminal output--Problem identified.

[Dmitri A. S. <das...@gm...>]

The sticky options may help with typing in a short  interactive
session, but generally
they are bad idea (in my opinion). E.g. you may have set some options
at the beginning of the session and later you want some different options.
Since you may have forgotten which options you did modify
the only sure way to get the desired options is to set terminal with
_all_ options
explicitly specified. What making thing worse is that "default" keyword
apparently does not set all options to the default state but only some.
Those problems become especially painful, when gnuplot is driven by an exte=
rnal
program (e.g. octave). See this thread for one example:

http://www.octave.org/octave-lists/archive/help-octave.2005/msg03471.html

Sincerely,

Dmitri.

On 10/1/05, Petr Mikulik <mi...@ph...> wrote:
> No, there is no bug. And it has nothing to do with "set term pop|push".
>
> According to "help set terminal":
>
>   Several terminals have many additional options.  For example, see `png`=
,
>   or `postscript`.
>   The options used by a previous invocation `set term <term> <options>` o=
f a
>   given `<term>` are remembered, thus subsequent `set term <term>` does
>   not reset them.  This helps in printing, for instance, when switching
>   among different terminals---previous options don't have to be repeated.
>
> Thus with
>   set term post eps
>   show term
>   set term post
>   show term
>
> it will stay with eps options.
>
> For postscript terminal, use "set term default" to reset to default value=
s.
> (However, this option is not available for other terminals.)
>
> > FYI
> >> From the octave list:
> >
> > Sincerely,
> >
> > Dmitri.
> >
> > ---------- Forwarded message ----------
> > From: John W. Eaton <jw...@be...>
> > Date: Sep 21, 2005 8:24 PM
> > Subject: Re: pslatex terminal output--Problem identified.
> > To: Pete Gustafson <wat...@ya...>
> > Cc: he...@oc...
> >
> > OK, I think this might be a bug in gnuplot.  You can reproduce it with
> > the following commands (these are essentially the commands that Octave
> > is sending to gnuplot, but plotting a function instead of a data file
> > to simplify things a bit)):
> >
> >  plot sin(x) title "line 1"
> >  set terminal push
> >  set term postscript eps enhanced color solid
> >  set output "foo.eps"
> >  replot
> >  set terminal pop
> >  set output
> >  replot
> >  set term pslatex
> >  set output "foo.tex"
> >  replot
> >  quit
> >
> > I have not looked at the code, so I am only guessing here, but it
> > seems that the problem might be that gnuplot is hanging on to some
> > postscript terminal options even after the set terminal pop statement
> > is executed.  If you insert something like
> >
> >  set term postscript landscape
> >
> > just after the set terminal pop statement, the problem goes away.  But
> > how can Octave know that it should do that?  It seems it would be
> > better for "set term pop" to restore the state of the terminal driver
> > to whatever it was when "set term push" was executed.
> >
> > Here is a simpler example.  Compare foo.eps vs. foo.ps from the
> > following two scripts.
> >
> > 1:
> >  plot sin(x) title "line 1"
> >  set terminal push
> >  set term postscript
> >  set output "foo.ps"
> >  replot
> >  set terminal pop
> >  set output
> >  replot
> >  set term postscript eps enhanced color solid
> >  set output "foo.eps"
> >  replot
> >  quit
> >
> > 2:
> >  plot sin(x) title "line 1"
> >  set terminal push
> >  set term postscript eps enhanced color solid
> >  set output "foo.eps"
> >  replot
> >  set terminal pop
> >  set output
> >  replot
> >  set term postscript
> >  set output "foo.ps"
> >  replot
> >  quit
> >
> > Looking at these I would expect foo.ps in both cases to be the simple
> > full page postscript plot.  But in the second case, both plots are
> > small eps style plots.
> >
> > I just checked the latest CVS gnuplot and it seems the behavior is the
> > same.  Would someone like to report this problem and find out if it is
> > intentional behavior or a bug?
> >
> > Thanks,
> >
> > jwe
>

Re: pslatex terminal output--Problem identified.

[Dmitri A. S. <das...@gm...>]

Ethan A Merritt wrote:
> On Sunday 02 October 2005 09:54 am, Dmitri A. Sergatskov wrote:
> 
>>Petr Mikulik wrote:
>>
>>>IMHO, these permanent options are a good idea even for interactive
>>>driving: for example, you can set terminals to "enhanced" mode in your
>>>.gnuplot file and don't need to do this in the driving program.
>>
>>I would need to do it
>>if somewhere in the middle of the session the mode has changed
>>to "noenhanced" for whatever reason...
> 
> 
> This is already supported in 4.1 via the "set termoption" command.
> "set termoption enhanced" will flip the current terminal into
> enhanced mode without changing anything else.
> 
> As of now only a limited subset of the possible terminal options
> can be changed mid-flight in this way: {no}enhanced and the
> default font.  Other options may be added, subject to the
> concern that the option must have the same meaning for multiple
> terminals.
> 

I guess I am not being clear. As I said, the problem with sticky options
is that it is impossible to predict what setting one going to get when
issued a command "set term post color". Let's say I am using a gnuplot
as a graphical backend to some program and I want to have a command 
"print" that does "set term post color; set output 'file.out'; replot".
The only way I can get a consistent format of the output graph if I 
specify explicitly _all_ the options to the "set term postscript" thing.
One example is when one does "set term post eps" and later
"set term pslatex". Since the "eps" option is sticky it messes up the
pslatex terminal...

Sincerely,

Dmitri.
-- 

Re: pslatex terminal output--Problem identified.

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

On Sunday 02 October 2005 09:54 am, Dmitri A. Sergatskov wrote:
> Petr Mikulik wrote:
> > IMHO, these permanent options are a good idea even for interactive
> > driving: for example, you can set terminals to "enhanced" mode in your
> > .gnuplot file and don't need to do this in the driving program.
>
> I would need to do it
> if somewhere in the middle of the session the mode has changed
> to "noenhanced" for whatever reason...

This is already supported in 4.1 via the "set termoption" command.
"set termoption enhanced" will flip the current terminal into
enhanced mode without changing anything else.

As of now only a limited subset of the possible terminal options
can be changed mid-flight in this way: {no}enhanced and the
default font.  Other options may be added, subject to the
concern that the option must have the same meaning for multiple
terminals.

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

Re: pslatex terminal output--Problem identified.

[Dmitri A. S. <das...@gm...>]

Petr Mikulik wrote:

> IMHO, these permanent options are a good idea even for interactive 
> driving: for example, you can set terminals to "enhanced" mode in your 
> .gnuplot file and don't need to do this in the driving program.
> 

I would need to do it
if somewhere in the middle of the session the mode has changed
to "noenhanced" for whatever reason... The issue here is that if I (or the
driving program) issues command "set term postscript" there is no way
to predict the result without knowing entire history of the current gnuplot
session. I cannot to see how this is a good idea.

> ---
> PM
> 

Sincerely,
Dmitri.
-- 

Re: Suggestions needed for a new command

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

On Thursday 29 September 2005 03:20 pm, Harald Harders wrote:
> 
> The valid suboptions have to be dependent on the chosen plotlayout.
> For  example, the DIN layouts need offsets, lengths, and styles for the arrows,
> while a background seems unlogical for plots without a border.

You might want a colored background for the XY plane in a 3D with 
xzeroaxis and yzeroaxis active, particularly if you are also drawing a
curve of some sort onto that plane.  And it is exactly in the case where
there is no border that you would want this the most. Right now you can
turn on the x and y grid lines, which is OK, but if we support backgrounds
at all it would be logical to support it for this purpose also.

But let's defer this until after the basic framework is in place.
 
> The question now is if different plotlayouts should use different routines
> to parse the command line or if it should be one routine which tests for
> every used option if it is valid for this layout (as for example the
> postscript-based terminals do).

If there is little overlap in the legal choice of suboptions, it's probably
better to let each style have its own parser.  In any case, duplicate code
can be merged later.
 
> Now, the question is who programmes what. I volunteer to programme the
> DIN 1 style. I think we should just leave out DIN 2 since it really is a
> strange thing to replace the last but one tic on an axis by its unit.

How about if you write both a type level parsing routine for
	set style plot$layout {border|axes|DIN|<others to be determined later}
and a specific parsing and initialization routine for the "DIN" case.
I'll provide a routine for the "axes" case, and either a suboption or a 
parallel one that handles your example of arrowheads on the axes.

"set style plot bordered" is simple, since it just resets to the current set
of default properties. But I guess we have to agree on exactly what properties
are being affected by these style settings, so we know what to reset.
I think the list so far is
	{xyz}zeroaxis
	{xyz}tics {axis|border}
	border
	arrowstyle for axes   # doesn't currently exist
Possibly also
	default key placement
	offsets for {xyz}label

Does the DIN style specification say anything about 3D plots?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Suggestions needed for a new command

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

On Thursday 29 September 2005 03:20 pm, Harald Harders wrote:
> On Thu, 29 Sep 2005, Ethan Merritt wrote:
> 
> And we should fix the strange behaviour of zeroaxis when an axis is near
> to the range limits, if the border is off. See the attached example.

The patchset I uploaded to start this discussion already does that.
It's not perfect, but it behaves reasonably for a far wider range of
cases than the current code does.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Suggestions needed for a new command

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

On Thursday 29 September 2005 03:20 pm, Harald Harders wrote:
> 
> What do you mean by linespacing?

The routine write_multiline() explicitly places each line of
text based on what it thinks the font size is, always using
a vertical increment of one character height.  This would 
allow you to adjust that spacing, either because it gets the
font size wrong or just because you want a different spacing.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Suggestions needed for a new command

[Harald H. <h.h...@tu...>]

On Thu, 29 Sep 2005, Ethan Merritt wrote:

> > I would prefer 'set style plot' because it really would open the way to
> > different layouts, as shown in the attachment. The DIN variant 2 is
> > strange but defined in the standard. I normally use DIN variant 1 which is
> > hard to get using current gnuplot because you always have to adapt the
> > position by hand.
>
> You have convinced me. Wow, I had no idea that DIN extended to telling
> people how to make their plots.

They standardise everything. :-)

> So the proposal so far is for a command with options
>
> 	set style plotlayout {bordered|axes|DIN1|DIN2|...}
>
> The default would be "set plotstyle bordered", which is what we have now.

This really sounds good.

> We could also consider allowing some suboptions to further tune the overall
> appearance. I have been keeping a list of requested features that
> would be easy to implement but have no obvious place to be specified
> in the current command set:
> 	{no}colorkeytitles
> 	{linespacing <n>}
> 	{background <rgbcolor>}

The valid suboptions have to be dependent on the chosen plotlayout. For
example, the DIN layouts need offsets, lengths, and styles for the arrows,
while a background seems unlogical for plots without a border.

The question now is if different plotlayouts should use different routines
to parse the command line or if it should be one routine which tests for
every used option if it is valid for this layout (as for example the
postscript-based terminals do).

What do you mean by linespacing?

> > Another thing I have always planned but not programmed is to provide the
> > position of an axis:
> >
> > set xzeroaxis at 3.5 # in 2D
> > set xzeroaxis at 3.5,4.2 # in 3D
> >
> > This would enable users to use zeroaxis also for plots that have a range
> > which does not include zero and for log-scale plots.
>
> I like that suggestion also, particularly if it means we can
> deprecate "set ticslevel", which no one can ever remember.

And we should fix the strange behaviour of zeroaxis when an axis is near
to the range limits, if the border is off. See the attached example.

Now, the question is who programmes what. I volunteer to programme the
DIN 1 style. I think we should just leave out DIN 2 since it really is a
strange thing to replace the last but one tic on an axis by its unit.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: _graphics() calls are not consistent here

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

Timoth=E9e Lecomte wrote:

>Hi !
>
>While working on my wxwidgets terminal, I have found the following
>strange behaviour :
>
>...
>
>However, when I rotate a pm3d plot with the mouse in my wxwidgets
>terminal, and in particular when samples are numerous (tried with set
>isosamples 200; splot x**2*y**2 with pm3d), it seems that _graphics is
>not always called.
>
>...
>
>And, as a consequence, I can see two plots in the window.
>Here is a screenshot to illustrate it : http://tipote.free.fr/wxt10.png
>
>I have digged into the code to see what can trigger such a problem, but
>can't find anything suspect...
>
>...
>
>Timoth=E9e Lecomte
>
Just for reference in the mailing list : I have found the error, in my
code. _graphics() are perfectly consistent !

Thanks to Ethan Merritt for his help on this case.

Timoth=E9e Lecomte

Re: Suggestions needed for a new command

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

On Thursday 29 September 2005 12:57 pm, Harald Harders wrote:
> On Thu, 29 Sep 2005, Ethan Merritt wrote:
> 
> > On Thursday 29 September 2005 03:00 am, Robert Hart wrote:
> >
> > > Something like:
> > >
> > > set plotstyle axes
> > > set plotstyle bordered

> I would prefer 'set style plot' because it really would open the way to
> different layouts, as shown in the attachment. The DIN variant 2 is
> strange but defined in the standard. I normally use DIN variant 1 which is
> hard to get using current gnuplot because you always have to adapt the
> position by hand.

You have convinced me. Wow, I had no idea that DIN extended to telling
people how to make their plots. Of the two, I like "set plotstyle" better
than "set style plot".

So the proposal so far is for a command with options

	set style plotlayout {bordered|axes|DIN1|DIN2|...}

The default would be "set plotstyle bordered", which is what we have now.

We could also consider allowing some suboptions to further tune the overall
appearance. I have been keeping a list of requested features that
would be easy to implement but have no obvious place to be specified
in the current command set: 
	{no}colorkeytitles
	{linespacing <n>}
	{background <rgbcolor>}

 
> Another thing I have always planned but not programmed is to provide the
> position of an axis:
> 
> set xzeroaxis at 3.5 # in 2D
> set xzeroaxis at 3.5,4.2 # in 3D
> 
> This would enable users to use zeroaxis also for plots that have a range
> which does not include zero and for log-scale plots.

I like that suggestion also, particularly if it means we can
deprecate "set ticslevel", which no one can ever remember.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Suggestions needed for a new command

[Harald H. <h.h...@tu...>]

On Thu, 29 Sep 2005, Ethan Merritt wrote:

> On Thursday 29 September 2005 03:00 am, Robert Hart wrote:
>
> > Something like:
> >
> > set plotstyle axes
> > set plotstyle bordered
>
> That's a possibility.  Although "plotstyle" is likely to be
> misunderstood as referring to dots/points/lines/boxes/etc

I also like this idea. As I am always using the DIN style which plots an
arrow parallel to the axis with the axis label. I could provide this style
as an option.

Other names could be:
set plotlayout
set style plot

> > which could be expanded later to include other "popular" styles
> >
> > set plotstyle excel
>
> Do I want to know what this looks like?  I hope you don't mean
> little pseudo-3D shaded skyscrapers that stand in for simple
> vertical lines or rectangles. But yes, I can imagine defining a
> number of common settings for the axes, borders, view angle, and so on.

No, this means too small fonts, no allowance of math in labels, and a
rescale to the default layout when embedding in other documents without
the possibility to change anything.

> I'm currently leaning in favor of
> 	set zeroaxis {only}
> or	set zeroaxis {noborder}

I would prefer 'set style plot' because it really would open the way to
different layouts, as shown in the attachment. The DIN variant 2 is
strange but defined in the standard. I normally use DIN variant 1 which is
hard to get using current gnuplot because you always have to adapt the
position by hand.

Another thing I have always planned but not programmed is to provide the
position of an axis:

set xzeroaxis at 3.5 # in 2D
set xzeroaxis at 3.5,4.2 # in 3D

This would enable users to use zeroaxis also for plots that have a range
which does not include zero and for log-scale plots.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Suggestions needed for a new command

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

On Thursday 29 September 2005 03:00 am, Robert Hart wrote:
> you mean a single command that does all of the above? 

Yes.

> Are there other examples? I guess the 2D equivalent?

"set view map" is an example.
That was why I considered extending it to "set view {map} {axes}".

The v4.0 docs say:
 `set pm3d map` is an abbreviation for 
 `set pm3d at b; set view map; set style data pm3d; set style func pm3d`.
 It is used for backwards compatibility, when `set view map` was not available.


> Something like:
> 
> set plotstyle axes
> set plotstyle bordered

That's a possibility.  Although "plotstyle" is likely to be 
misunderstood as referring to dots/points/lines/boxes/etc

> which could be expanded later to include other "popular" styles
> 
> set plotstyle excel

Do I want to know what this looks like?  I hope you don't mean
little pseudo-3D shaded skyscrapers that stand in for simple
vertical lines or rectangles. But yes, I can imagine defining a
number of common settings for the axes, borders, view angle, and so on.


I'm currently leaning in favor of
	set zeroaxis {only}
or	set zeroaxis {noborder}


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: How about a fresh release ?

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

On Wednesday 28 September 2005 11:47 pm, Petr Mikulik wrote:
> 
> > Passing an X window ID into the program:  I don't think this is in yet. 
> > I'm not particularly motivated to include it, but someone else requested 
> > that I add it.  It seemed such a small addition that it should be bug 
> > free, or easy to fix if a bug does come up.  (Writing the xWidgets program 
> > to demo the thing was by far more difficult.)
> 
> I vote for this inclusion. Very useful.

I agreee that it would be useful.
Unfortunately I have never been able to get the current patchset to
work on my machines, so I think it will need either additional 
debugging or additional documentation and demonstratation code
chunks that show how to make it work.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Suggestions needed for a new command

[Robert H. <en...@no...>]

On Wed, 28 Sep 2005, Ethan Merritt wrote:

> There are two problems with the "set ticslevel" command.
> 1) It isn't easy to do in a script, since you don't necessarily
> know in advance what are the values of YMIN and YMAX
> 2) It breaks anyhow if you later change zrange.

I suppose the ticslevel command could be "adapted" to take absolute
coordinates. Something like:

set ticslevel relative 0.5  # works as before
set ticslevel absolute 0    # is a z-value for the XY-plane

The relative keyword would of course be optional. "absolute" could be
"zvalue" or simply "z", and "zmin" and "zmax" would be nice shortcuts for 
set ticslevel 0 and set ticslevel 1 (or is it -1?)

It does strike me that the name "ticslevel" is not the most descriptive of
what it does. I think I've had to look it up on more than one occasion and
always start with things like "offset" first.

> I want a new command that does the equivalent of the 8 commands above, 
> except that it bypasses the existing "set ticslevel" mechanism in
> favor of pinning the X/Y plane at Z=0.

you mean a single command that does all of the above? That seems like a
good idea, because that would seem to be a sequence of commands that would
frequently come together. Are there other examples? I guess the 2D
equivalent?

Something like:

set plotstyle axes
set plotstyle bordered

which could be expanded later to include other "popular" styles

set plotstyle excel

maybe?

> It's not clear to me whether this would fit in as a variant of 
> some existing command, or whether it would need a new one of its own.
> Possibilities include
> 
> 	set view axes

doesn't that conflict slightly with the existing use of "view"



This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Re: How about a fresh release ?

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

>> 1) outdated ---> tag as such, and close.
>> 2) keeper --> tag 'release-critical', integrate in good time, then close
>> 3) later --> tag 'later', keep open

I propose that within the following month or so, we should clean up the 
Patches section, and our own bug et al notes, and freeze gnuplot in 
November.

> Passing an X window ID into the program:  I don't think this is in yet. 
> I'm not particularly motivated to include it, but someone else requested 
> that I add it.  It seemed such a small addition that it should be bug 
> free, or easy to fix if a bug does come up.  (Writing the xWidgets program 
> to demo the thing was by far more difficult.)

I vote for this inclusion. Very useful.

> Raise/lower for X windows:  Don't know the status of that one.  May be 
> some group reluctance because other window platforms might not have it. 
> Code wise, no brainer.

I use it for ages and it works OK (for all x11, pm and windows). Should be 
committed.

---
PM

Re: Re: How about a fresh release ?

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

    My 2 cents :

    A new release would sure do Gnuplot a lot of good. I absolutely
love the new features of 4.1 (better rgb colors and image support, these
two are enough for me to justify a release).
    It would also be good to get feedback from the users.

    However, I don't really think that I have my word to say, since I
certainly won't be helping much for that release.

--
    Ga=EBl

Re: Re: How about a fresh release ?

[<ds...@ch...>]

I wrote this the other day, then put it in my draft folder...  (So, I'd g=
o with the "tracker page" concept.)

> Timoth=E9e Lecomte wrote:
> > I was wondering if it wasn't the good moment to do a fresh release of
> > gnuplot, I mean "gnuplot 4.1".
>=20
> I think it's way too early for that.  Worse yet, I'd have to be the one=
=20
> to do it, and I don't see where I could steal the time for that right=20
> now.  Last time took about us 6 weeks of preparation, the last two of=20
> them nearly full-time on my end of things.

Yes, but that was a major upgrade spanning back 5+ years, having switched=
 archive locations to SourceForge, a fully new home page by Ethan--many p=
roblems that would've been spread out had releases been done more often. =
 My thinking is the code has gotten much cleaaner and the developers with=
 CVS access have been very prompt about jumping on bugs that find their w=
ay into the code.

>  People have got used to a
> "release early --- release often" strategy.  Sorry, but with the=20
> licensing issues as they are, that's a non-option for gnuplot.
>=20
> That set aside, I don't think the code currently has the level of=20
> maturity people rightfully expect from a release version of gnuplot.=20
> There's way too much on-going activity on the 'adding features' front=20
> for that.  We have to let the dust settle a bit before a release can be=
=20
> considered in earnest.

Agreed.  But still, I think compared to the position we were in when deve=
lopers decided to release 4.0, we're already much further along.

>=20
> The most we could usefully do right now is a general review of open=20
> patches and feature requests, with a view towards making a three-way=20
> decision for each and every one of them:
>=20
> 1) outdated ---> tag as such, and close.
> 2) keeper --> tag 'release-critical', integrate in good time, then clos=
e
> 3) later --> tag 'later', keep open

Also, how about on the web page we have a "future items" list.  Something=
 we all have accesss to and won't get lost.  That is, rather than writing=
 the "new features" subsection of the release notice _after_ the release =
is ready, let's do it _before_ the release process is begun.  That will h=
alt the new features added to the release candidate for a few months.

So I will offer up a couple things for the list if we were to start one:

Image Plotting:  We've covered the major output formats except for Window=
s, I think...  I know little about windows resources.

Binary Data Input:  I think Petr and I have shaken out the bugs and preve=
nted any kind of major program breakage that could come from trying to in=
terpret binary data.  I understand this may be a bit dodgy for some becau=
se of the low use for interactive users.  But it is aimed for interchangi=
ng data between programs, not trying to read someone's generic, small, un=
defined raw data.

Faster Data Input?:  On that note, after the fact of using binary data to=
 speed up data transfer for images came a discussion about the scanf() fu=
nction having major slowdown for long line reads... something I only unde=
rstood in concept, i.e., having to rescan previous entries on the line or=
 something.  But of course, this probably contributed to the problem of t=
ransferring ASCII image files taking many seconds.  Will this scanf() slo=
wdown be addressed in this release?  Or are we at the mercy of any compil=
ers on this one?

Passing an X window ID into the program:  I don't think this is in yet.  =
I'm not particularly motivated to include it, but someone else requested =
that I add it.  It seemed such a small addition that it should be bug fre=
e, or easy to fix if a bug does come up.  (Writing the xWidgets program t=
o demo the thing was by far more difficult.)

More advanced key placement:  Needs debugging.  No crash bugs, instead th=
e "that shouldn't go there for this option" kind of thing.  I'll get to t=
his within a month when I get back to my home base.

Some compile problems with #ifdef chunks in gnuplot_x11 based upon config=
urations at the ./config command line.  Again, within a month.

Raise/lower for X windows:  Don't know the status of that one.  May be so=
me group reluctance because other window platforms might not have it.  Co=
de wise, no brainer.

Dan