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

pasting code into gnuplot

[Arnd B. <arn...@we...>]

Hi,

I just installed the current CVS of gnuplot
and encounter the following problem under X11:
Marking and pasting (with the middle mouse button)
the following few lines
######
set xrange [0:10]
print "blurb"
plot sin(x)
set out "tst.ps"
set term post
rep
set out
set term x11
######
into a freshly started gnuplot session
only the lines until `plot sin(x)` (inclusive)
are accepted (i.e. pasted)
and that's it.
((Also the "paste-buffer"
seems to get emptied, i.e. directly following
paste produces nothing (neither in gnuplot nor xemacs).))
Redoing the copy and paste a second time
it works as expected.
(setting `unset mouse` or -nofeedback did not change anything).

Can someone else reproduce this behaviour?
((This type of problem was there before some time ago
and somehow I thought that this was resolved ;-),
but maybe I am wrong...))

Best,

Arnd

P.S.: platform: debian linux, testing, gcc version 3.3.2
      (if that matters)
P.P.S.: It also seems that there are some problems with piping
      into gnuplot, but I will have to investigate this further
      (+read the posts on this again ;-) ...

Re: autoconf macro AC_FUNC_SELECT

[Hans-Bernhard B. <br...@ph...>]

On Thu, 25 Dec 2003, Jim Van Zandt wrote:

> I tried to fix that by moving the files aside and recreating them, but
> had a lot of trouble getting configuration working again.  I got a lot
> of warnings from automake (or maybe it was autoconf) about an invalid
> macro AC_FUNC_SELECT.  "prepare" didn't help.  Eventually I stumbled
> on a combination of automake, autoconf, aclocal, and prepare that is
> working. 

AC_FUNC_SELECT is a macro provided by the gnuplot sourcecode itself (it's 
in gnuplot/m4/select.m4).  It's supposed to be imported through 
aclocal.m4.  That's why prepare runs aclocal with the flag -I m4.

Any chance one of the relevant files is checked out to a fixed version
in your working copy?

>   # Note that both autoconf 2.13/automake 1.5 and autoconf 2.5x/automake
>   # 1.7 or newer may be used, although the gnuplot project continues to
>   # use the former

That comment is, indeed, outdated.  AC_PREREQ() is the hard fact.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: contouring broken with hidden3d on

[Hans-Bernhard B. <br...@ph...>]

On Thu, 25 Dec 2003, Don Taber wrote:

> Contouring is broken in current cvs when hidden
> line removal is on.  Maybe a result of recent patch to fix
> breaks in contour lines?

Definitely.  The way hidden3d works is fundamentally incompatible with
keeping contour lines contiguous, anyway, but the patch breaks quite a bit
more badly than it has to.  

Expect an update of that soon.


-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: howto drive wgnuplot.

[Hans-Bernhard B. <br...@ph...>]

On Wed, 24 Dec 2003, Knoppix User wrote:

> i need a 2d library to plot a function in my application. is there a way
> to call wgnuplot from an other c++ application.

Yes.  You _popen() the pgnuplot.exe helper program and send your commands
to that pipe.

> or even simpler for the user to statically link gnuplot into my
> application. 

Not at this time, in any publically accessible version.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: tic marks for transformed axes

[Hans-Bernhard B. <br...@ph...>]

On Mon, 22 Dec 2003, Jim Van Zandt wrote:
> Hans-Bernhard Broeker <br...@ph...> wrote:

> >"Reasonable" being as subjective and volatile a quality as it is, that's
> >indeed a noble quest you've set out on ;-)
> 
> By "reasonable" I mean "strictly monotonic".

I would hope to restrict that a little further, to continuous, or even
differentiable functions. We'll have to invert those functions,
eventually, and that's a bitch to do if there are jumps in the input or
intervals where the function isn't defined...

> >>  - Don't allow tic labels to overlap.
> >
> >This is already quite hard to do, in general...
> 
> At the moment, the function uses a simple estimate.  Once it's
> integrated into gnuplot, it can use v_char and h_char.  Where that's
> not enough, maybe we could implement a user-supplied scaling
> parameter for h_char (so it would apply to all strings).

Or put to use the "guess" parameter the current algorithm already has
(currently fixed at 20, for hysterical reasons). Tell it to use fewer tics
if the font is large or the labels take up too much space.

> >> 1. Provide for user mini-tics.  Currently the user can provide tic marks
> 
> so the documentation would be something like this:
> 
>    Syntax:
>          set xtics ... ({"<label>"} <pos> {level} {,{"<label>"}...) }
>    ...
>    The explicit ("<label>" <pos> <level>, ...) form allows arbitrary tic
>    positions or non-numeric tic labels.  In this form, the tics do not
>    need to be listed in numerical order.  Each tic has a 
>    position, optionally with a label.  Note that the label is
>    a string enclosed by quotes.  It may be a constant string, such as
>    "hello", may contain formatting information for converting the
>    position into its label, such as "%3f clients", or may be empty, "".
>    See `set format` for more information.  If no string is given, the
>    default label (numerical) is used.

I'm not sure that we actually can support %3f in the label string
of an explicit tic list, right now.  If you want the number formatted into 
the label, you currently have to leave out the label string and fall back
to 'set format', as far as I'm aware.

>    An explicit tic mark has a third parameter, the "level".  The default
>    is level 0, a major tic.  A level of 1 generates a minor tic.  If the
>    level is specified, then the label must also be supplied.

No.  Something like

	set xtics (1 1, 2 1, 3 2, 4 2)

should be allowed.  If only because it's awkward to express optional
entries being coupled to each other on two sides of a non-optional one,
in the syntax short-hand.

> The only awkward part is that minor tics are signaled twice - once by
> the empty label string and again by the nonzero level.  However, it
> maintains upward compatibility, and as you say it generalizes to more
> sizes of tics.

And to labelled minors right away.

> >and 'set log x'
> >would then internally be mapped to 'set transform x log10(x)'
> 
> Okay.  My first instinct is to hold off on this last step until the
> new transformed autotic function is thoroughly tested.  On the other
> hand, using it for log plots by default will certainly exercise it
> more!

Definitely.  Getting those log-ticks to behave sensibly in the face of
round-off errors was _very_ tricky business.  Just check out all that
business about having to look at the precision of the %l part to correctly
round the %L part in a

	set format x '%5.3l * b^%L'

situation...

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: tic marks for transformed axes

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

On Friday 26 December 2003 03:26 pm, Jim Van Zandt wrote:
>
> I've checked code into CVS that implements levels 0 and 1.
> I'd appreciate if you would run the demo

Jim:

	I ran into a minor issue when updating my patch for
handling string data so that it would apply on top of your new
code.  My patch revises add_tic_user() so that it maintains the
tic entries as sorted lists, allowing only one tic entry for any
given axis coordinate. Your demo scripts revealed a difference
between my patched version and the current behaviour,
but in thinking about it I decided both were incorrect.

The issue is what to do when a minor tic entry and a 
major tic entry both have the same coordinate.  My code
was keeping whichever was specified last.  The current
code keeps both.  Either way potentially causes a
problem, either by over-printing two labels at the same 
place or by losing a desired tic label.

I modified my patch so that only the tic with the lowest
"level" code is kept; i.e. major tics trump minor tics.
This makes your demo scripts behave the same as on
the unpatched cvs version.
I *think* this is the right thing to do, but maybe someone
can offer arguments for a different approach.  Would there
ever be explicit minor tic labels that should over-ride the
[possible null] major tic labels?

I don't see an easy way to even detect this condition in
the current code, though.  So if both major tic labels and
minor tic labels are present they will print on top of each
other at major tic locations.  Maybe we can live with this
though the next release.   Or else I could break out just
the sorted-tic-lists part of the datastrings patch and apply
that to the cvs version sooner rather than later. 

What do you all think?


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: tic marks for transformed axes

[Jim V. Z. <jr...@co...>]

Hans-Bernhard Broeker <br...@ph...> wrote:
>While I do like the general idea of allowing user-placed minitics, I
>strongly dislike that syntax.  Making a distinction between '' and ' '
>is bound to counter-intuitive...
>
>Here's a possible alternative, which would also allow for a possible
>extension to more than 2 kinds of tics in the future:
>
>	set xtics ("bottom" 0 0, "" 10 0, "" 13 2, \
>                   "here" 14 1, "top" 20)
>
>which would express that there are labelled major (level-0) tics at 0
>and 20, an unlabelled major at 10, an unlabelled sub-minor tic at 13,
>and a labelled minor tic (level 1) at 14.

I've checked code into CVS that implements levels 0 and 1.

I've also updated my demo program at http://jrv.oddones.org/ to use
the new syntax.  I'd appreciate if you would run the demo
(i.e. download http://jrv.oddones.org/transform-0.6.tar.gz, unpack,
and type "make plots").  

I'll be working on the tic routines over the next few days, but will
be traveling so probably won't see any discussion until I return.

	   - Jim Van Zandt

contouring broken with hidden3d on

[Don T. <dt...@to...>]

Contouring is broken in current cvs when hidden
line removal is on.  Maybe a result of recent patch to fix
breaks in contour lines?

Don Taber

autoconf macro AC_FUNC_SELECT

[Jim V. Z. <jr...@co...>]

Lately when I do "cvs update" I get a series of warning like this:

 cvs server: conflict: Makefile.in is modified but no longer in the repository

I tried to fix that by moving the files aside and recreating them, but
had a lot of trouble getting configuration working again.  I got a lot
of warnings from automake (or maybe it was autoconf) about an invalid
macro AC_FUNC_SELECT.  "prepare" didn't help.  Eventually I stumbled
on a combination of automake, autoconf, aclocal, and prepare that is
working.  However, there seems to be a problem...

prepare claims:

  # Note that both autoconf 2.13/automake 1.5 and autoconf 2.5x/automake
  # 1.7 or newer may be used, although the gnuplot project continues to
  # use the former
  
However, autoconf 2.13 quits immediately because configure.in contains:

  AC_PREREQ(2.52)

I guess the comment in prepare is out of date.

configure.in also contains:

  dnl Argument types of select()
  AC_FUNC_SELECT

but AC_FUNC_SELECT is not documented in either autoconf 2.13 or 2.58.

Indeed, when I run configure I get this warning:
  
  ./configure: line 6936: AC_FUNC_SELECT: command not found

I guess it was replaced by AC_FUNC_SELECT_ARGTYPES, which
first appeared in autoconf 2.13 (May '99). 

I trace the usage like this:
  src/gplt_x11.c uses SELECT_FD_SET_CAST like this:

	nf = select(nfds, SELECT_FD_SET_CAST & tset, 0, 0, timer);

  which is defined in stdfn.h like this:

        #ifndef SELECT_FD_SET_CAST
        # define SELECT_FD_SET_CAST
        #endif

  In principle, SELECT_FD_SET_CAST could also be defined in config.h, 
  depending on config.hin and the results of autoconf tests
(e.g. AC_FUNC_SELECT). Apparently since AC_FUNC_SELECT never runs,
SELECT_FD_SET_CAST never really contributes anything.
  
I suggest:
  update the comment in "prepare" to require autoconf 2.5x/automake 1.7
  delete the reference to AC_FUNC_SELECT in configure.in
  delete SELECT_FD_SET_CAST from gplt_x11.c.

Alternatively:
  configure.in should call AC_FUNC_SELECT_ARGTYPES
  in gplt_x11.c (and also in src/fit.c), the second argument to select
should be cast to SELECT_TYPE_ARG234.  Likewise cast the first
argument to SELECT_TYPE_ARG1 and the last argument to SELECT_TYPE_ARG5.
  
Are the nonstandard version of select() common enough to justify the latter?

		- Jim Van Zandt

howto drive wgnuplot.

[Knoppix U. <as...@cl...>]

i need a 2d library to plot a function in my application. is there a way
to call wgnuplot from an other c++ application.or even simpler for the
user to statically link gnuplot into my application.
if yes. please let me know
thanks
any help is very much apreciated.

Re: updated faq

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

On Monday 22 December 2003 13:55, Petr Mikulik wrote:
> I've modified faq.tex on sourceforge:
> Please have a look too.

OK.  I made a pass over it also.

> There are definitely some URLs that needs to prove whether they exists.

I didn't go through all of these - still needs to be done.

> There is a (for me) "strange section" on pgm, pbm et al formats and
> utilities. Maybe it needs a rewrite?

I took it out, in favor of a general statement about using ImageMagick
or the Gimp to process pixel-based image output.  I also deleted=20
discussions that date back to the 'good old days' of the net; e.g.
recommendations to look for files using archie.

Question:

Is it really possible for external users to send mail to
gnu...@li...?
I had the impression that only mail from subscribers gets through to
the list.

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

Re: tic marks for transformed axes

[Jim V. Z. <jr...@co...>]

Hans-Bernhard Broeker <br...@ph...> wrote:
>
>> I'd like to generalize this, at least for the equivalent of "probability
>> paper" and "weibull plots", and preferably for any reasonable
>> user-supplied function. 
>
>"Reasonable" being as subjective and volatile a quality as it is, that's
>indeed a noble quest you've set out on ;-)

By "reasonable" I mean "strictly monotonic".

>>  - Don't allow tic labels to overlap.
>
>This is already quite hard to do, in general...

At the moment, the function uses a simple estimate.  Once it's
integrated into gnuplot, it can use v_char and h_char.  Where that's
not enough, maybe we could implement a user-supplied scaling
parameter for h_char (so it would apply to all strings).

>> 1. Provide for user mini-tics.  Currently the user can provide tic marks
>> with a command like
>>   set ytics ("bottom" 0, "" 10, "top" 20) 
>> 
>> However, only full size tic marks can be generated by this mechanism.
>> I propose a patch below that will generate a minitic for a null label
>> "".  The user can still get a full size tic with no label by putting
>> one or more spaces in the label string.
>
>While I do like the general idea of allowing user-placed minitics, I
>strongly dislike that syntax.  Making a distinction between '' and ' '
>is bound to counter-intuitive...
>
>Here's a possible alternative, which would also allow for a possible
>extension to more than 2 kinds of tics in the future:
>
>	set xtics ("bottom" 0 0, "" 10 0, "" 13 2, \
>                   "here" 14 1, "top" 20)
>
>which would express that there are labelled major (level-0) tics at
>0 and 20, an unlabelled major at 10, an unlabelled sub-minor tic at 13,
>and a labelled minor tic (level 1)  at 14.

so the documentation would be something like this:

   Syntax:
         set xtics ... ({"<label>"} <pos> {level} {,{"<label>"}...) }
   ...
   The explicit ("<label>" <pos> <level>, ...) form allows arbitrary tic
   positions or non-numeric tic labels.  In this form, the tics do not
   need to be listed in numerical order.  Each tic has a 
   position, optionally with a label.  Note that the label is
   a string enclosed by quotes.  It may be a constant string, such as
   "hello", may contain formatting information for converting the
   position into its label, such as "%3f clients", or may be empty, "".
   See `set format` for more information.  If no string is given, the
   default label (numerical) is used.
  
   An explicit tic mark has a third parameter, the "level".  The default
   is level 0, a major tic.  A level of 1 generates a minor tic.  If the
   level is specified, then the label must also be supplied.
  
   Examples:
         set xtics ("low" 0, "medium" 50, "high" 100)
         set xtics (1,2,4,8,16,32,64,128,256,512,1024)
         set ytics ("bottom" 0, "" 10, "top" 20)
         set ytics ("bottom" 0, "" 10 1, "top" 20)
  
   In the second example, all tics are labelled.  In the third, only the end
   tics are labelled.  In the fourth, the unlabeled tic is a minor tic.

The only awkward part is that minor tics are signaled twice - once by
the empty label string and again by the nonzero level.  However, it
maintains upward compatibility, and as you say it generalizes to more
sizes of tics.

>> The algorithm is more complicated than I like, but I could not get any
>> of the simpler things I tried to work.  There are still some cases
>> that don't come out right.

However, it handles a lot of cases well :-)

>> I propose leaving "logscale" alone, but adding a "transform" option to
>> xtics as follows:
>> 
>>        set xtics {axis | border} {{no}mirror} {{no}rotate {by <ang>}}
>>                  {  autofreq
>>                   | <incr>
>>                   | <start>, <incr> {,<end>}
>>                   | ({"<label>"} <pos> {,{"<label>"} <pos>}...)
>>                   | transform <function> }
>>                  { font "name{,<size>}" }
>>                  { textcolor <colorspec> }
>
>No. If we do add axis transformation, it really must be applied not only
>to the tics, but to the plotted data, too, so this option has no business
>hiding itself under the coat of 'set xtics'.  This really should become a
>new command 'set transform {x|y|x2|y2|z|c} <function>', 

agreed

>and 'set log x'
>would then internally be mapped to 'set transform x log10(x)'

Okay.  My first instinct is to hold off on this last step until the
new transformed autotic function is thoroughly tested.  On the other
hand, using it for log plots by default will certainly exercise it
more!

I'll work on implementing user mini-tics with your syntax, unless
someone comes up with a better idea.

		- Jim Van Zandt

updated faq

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

I've modified faq.tex on sourceforge:
- Added questions about pm3d, mousing and hotkeys.
- Added and modified various questions related to the forthcoming
  gnuplot 4.0.
- Various small or large changes and fixes, e.g. URLs.

Please have a look too.

There are definitely some URLs that needs to prove whether they exists.

There is a (for me) "strange section" on pgm, pbm et al formats and
utilities.
Maybe it needs a rewrite?

---
Petr Mikulik

Re: tic marks for transformed axes

[Hans-Bernhard B. <br...@ph...>]

On Sat, 20 Dec 2003, Jim Van Zandt wrote:

> 
> At present, gnuplot only knows about linear and log axes, and with a
> log axis only the powers of 10 are labeled.  

Powers of the logarithm base, to be precise.  Try 'set log x 2.0'
once in a while...  But in general, you're right.  See my long-open
bug report "short log axes get bad autotics" on SF.

> I'd like to generalize this, at least for the equivalent of "probability
> paper" and "weibull plots", and preferably for any reasonable
> user-supplied function. 

"Reasonable" being as subjective and volatile a quality as it is, that's
indeed a noble quest you've set out on ;-)

>  - Don't allow tic labels to overlap.

This is already quite hard to do, in general.  Note that for quite a
subset of drivers, including the entire PostScript and TeX family, gnuplot
has no real idea at all how large a given tic label is actually going to
be on output.

> 1. Provide for user mini-tics.  Currently the user can provide tic marks
> with a command like
>   set ytics ("bottom" 0, "" 10, "top" 20) 
> 
> However, only full size tic marks can be generated by this mechanism.
> I propose a patch below that will generate a minitic for a null label
> "".  The user can still get a full size tic with no label by putting
> one or more spaces in the label string.

While I do like the general idea of allowing user-placed minitics, I
strongly dislike that syntax.  Making a distinction between '' and ' '
is bound to counter-intuitive to almost every single non-guru user of
gnuplot out there.

Here's a possible alternative, which would also allow for a possible
extension to more than 2 kinds of tics in the future:

	set xtics ("bottom" 0 0, "" 10 0, "" 13 2, \
                   "here" 14 1, "top" 20)

which would express that there are labelled major (level-0) tics at
0 and 20, an unlabelled major at 10, an unlabelled sub-minor tic at 13,
and a labelled minor tic (level 1)  at 14.

> I propose that this part (only) be integrated into gnuplot version 4.0.

> The algorithm is more complicated than I like, but I could not get any
> of the simpler things I tried to work.  There are still some cases
> that don't come out right.

I supsected as much, having fought with the time/date variety of this
problem a while ago, and having tried to solve the "generalized axis
mapping" problem.

The best I could come up with was to have the user specify a
transformation function from plotted values to some artificial scale, then
use an improved version of the normal, linear auto-ticking algorithm on
that axis.  Whenever the auto-ticking algorithm working on the transformed
scale determines an interval smaller than, say, 1.0, or a user-choosable
threshold, tics would be placed equidistant in the real coordinates, 
per integer interval of the transformed scale.  That'd imitate what the
current logscaled autoticking in gnuplot docs, but extend sensibly to
short-range log axes and hopefully to transformed axes, too.

> I propose leaving "logscale" alone, but adding a "transform" option to
> xtics as follows:
> 
>        set xtics {axis | border} {{no}mirror} {{no}rotate {by <ang>}}
>                  {  autofreq
>                   | <incr>
>                   | <start>, <incr> {,<end>}
>                   | ({"<label>"} <pos> {,{"<label>"} <pos>}...)
>                   | transform <function> }
>                  { font "name{,<size>}" }
>                  { textcolor <colorspec> }

No. If we do add axis transformation, it really must be applied not only
to the tics, but to the plotted data, too, so this option has no business
hiding itself under the coat of 'set xtics'.  This really should become a
new command 'set transform {x|y|x2|y2|z|c} <function>', and 'set log x'
would then internally be mapped to 'set transform x log10(x)'

Re: filledboxes in CGM terminal

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

> I implemented filledboxes in the CGM terminal.  May I eliminate this
> item from the TODO file?

Sure.

Re: Please use this bug report instead... thanks.

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

John W. Eaton wrote:

>On  4-Jul-2003, Daniel J Sebald <dan...@ie...> wrote:
>  
>
<snip>

>| the gnuplot group has discussed. I guess the main
>| issue to Octave developers might be "how could
>| such a thing work nicely through a pipe".
>
>Sorry for not responding until now.
>

That's fine John.  I see that the Octave developers have been doing a 
lot of stuff lately.

>I think image overlays on graphs might be interesting.  Binary data
>transer to gnuplot would also be nice, as would the elimination of
>temporary files.
>

I'm uploading a PDF version of the demo that goes along with the "with 
image" patch that is at Gnuplot's SourceForge site to my web page. 
 (Let's hope it all fits in my web space...)  If the file makes it, go 
to the web page listed below after removing the spaces I put in the 
address.  Look under "gnuplot stuff" and then look for the file 
"image.pdf"...  OK, it just finished transferring and is complete.

I and, I think, a lot of the Gnuplot list people using Octave don't like 
the temporary file solution either.

>Regarding elimination of temporary files, there were some problems
>with that when I tried it, related to the requirement that subsequent
>replot commands also need to pass the data back to gnuplot and Octave
>is not set up to handle that.
>

Yes, that is an issue.  This is something that has been discussed 
several times on the list.  Gnuplot's current paradigm is a "terminal". 
 Some have suggested having something more object oriented where all 
information necessary for replotting is kept internal to Gnuplot. 
 However, that is just an idea and if it were to happen it would be 
rather far down the road I think.

>Do you know if there will ever be another gnuplot release?  (I know,
>you could ask the same about Octave.)  It's easier for a package like
>Octave to use the new features of gnuplot if they appear in a released
>version.
>

Yes, the trend appears to be a non beta version, 4.0, in the near 
future.  The developers are putting a lot of work into seeking out any 
remaining problems.  Images and binary data will be after 4.0 because 
that is quite a bit of new syntax and hasn't been tested by too many 
developers, although some of the developers have added features such as 
PDF/PNG drivers and EDF data file access.

>Finally, do you think there will ever be a reasonably clean C
>interface to the gnuplot internals?  It would certainly be better than
>working through a pipe.  Alternatively, is there a reliable way to
>query gnuplot about its internal state from an external program?  It
>would be very useful if Octave could ask gnuplot what the current
>setting of the terminal type is, for example.  I'd rather not have to
>rely on parsing potentially arbitrary text output since that could
>easily change from version to version and then my output parser would
>quit working properly.
>
>If you have other ideas or questions, post them to the help-octave,
>octave-graphics, or octave-maintainers mailing list(s) as you feel
>appropriate.
>
>Thanks,
>
>jwe
>

Regarding the first issue of a C interface, my guess would be no.  The 
syntax is more the standard in Gnuplot, and from what I've observed of 
the code it doesn't resemble a library-like construction.  Personally, I 
don't find the pipe interface to be too bad, given that I have used 
Gnuplot for my own unrelated GUI program.  Oh BTW, the upcoming Gnuplot 
release should have the X11 sixteen plot limit removed, and there will 
be a way to label the window and a way to close a window.

I'm carbon copying to the gnuplot discussion list.  Someone there might 
know about the internal state issue.  I've read it discussed a few times 
but I hadn't paid too close attention.

Regards,

Dan

-- 

Dan Sebald
email: daniel . sebald @ ie ee . o rg
URL: ht tp://acer-access.c om/~dsebald @ acer-access.c om/

tic marks for transformed axes

[Jim V. Z. <jr...@co...>]

At present, gnuplot only knows about linear and log axes, and with a
log axis only the powers of 10 are labeled.  I'd like to generalize
this, at least for the equivalent of "probability paper" and "weibull
plots", and preferably for any reasonable user-supplied function.
I've written a function that attempts to place tics according to these 
rules:

 - Place no tics or minitics outside the range specified by the user.

 - Don't allow tic labels to overlap.

 - Choose the "simplest" tics to label (i.e. those with the fewest
   significant digits).

 - Subject to the above, place tics with approximately even density.

 - Ensure the value corresponding to each minitic is obvious.

 - Subject to the above, place enough minitics that the user can
   easily interpolate to find the value for any point on the graph.

I propose a four-step implementation process:

1. Provide for user mini-tics.  Currently the user can provide tic marks
with a command like
  set ytics ("bottom" 0, "" 10, "top" 20) 

However, only full size tic marks can be generated by this mechanism.
I propose a patch below that will generate a minitic for a null label
"".  The user can still get a full size tic with no label by putting
one or more spaces in the label string.

I propose that this part (only) be integrated into gnuplot version 4.0.

2. Algorithm.  I have written a function to generate labels, tics, and
minitics for an axis that has undergone a user-supplied transform, and
a driver program with several transforms builtin, including log,
normal probability, and weibull probability.  The driver program
writes out tic mark generating commands (as above).  One example is
appended below.  Please apply the patch to see the full effect.  For
some other examples and the program sources, see
  http://jrv.oddones.org

The algorithm is more complicated than I like, but I could not get any
of the simpler things I tried to work.  There are still some cases
that don't come out right.

With the external program, a user can get a correctly labeled plot,
but she must include the transformation in the plot command.  For
example:

  set logscale x 10
  set xlabel "yield strength, kg/mm^2"
  set ylabel "unreliability"
  set yrange [ -4.80000 : 2.00000 ] noreverse nowriteback
  set label "see: http://www.reliasoft.com/newsletter/2q2001/classic_weibull.htm" \
  	at graph .98,.1 right
  load 'steel.tic'
  plot 'steel.dat' u ($3-38.57):(log(log(1/(1-$1/390))))


3. Decide on command syntax.

The current commands for specifying axes are:

       set logscale <axes> <base>
       unset logscale <axes>
       set xtics {axis | border} {{no}mirror} {{no}rotate {by <ang>}}
                 {  autofreq
                  | <incr>
                  | <start>, <incr> {,<end>}
                  | ({"<label>"} <pos> {,{"<label>"} <pos>}...) }
                 { font "name{,<size>}" }
                 { textcolor <colorspec> }
       unset xtics

I propose leaving "logscale" alone, but adding a "transform" option to
xtics as follows:

       set xtics {axis | border} {{no}mirror} {{no}rotate {by <ang>}}
                 {  autofreq
                  | <incr>
                  | <start>, <incr> {,<end>}
                  | ({"<label>"} <pos> {,{"<label>"} <pos>}...)
                  | transform <function> }
                 { font "name{,<size>}" }
                 { textcolor <colorspec> }

The function must have exactly one variable.

So as an alternative to the above, the user could write
  f(x) = log10(x)
  set xtics transform f
  g(y) = log(log(1/(1-y)))
  set ytics transform g

  plot 'steel.dat' u ($3-38.57):($1/390)

which would use the new algorithm to place minitics, regular tics, and
labels on both axes

4. Integration.  I have not looked into this.  


The patch for user-specified minitics follows.

		- Jim Van Zandt



--- ./src/axis.c-orig	Thu Feb  6 21:23:31 2003
+++ ./src/axis.c	Thu Feb  6 21:42:48 2003
@@ -888,16 +888,20 @@
 
 	    if (!inrange(internal, internal_min, internal_max))
 		continue;
-
+	    /* use supplied format if any.  If nothing is supplied, use
+             * default format. 
+	     */
 	    if (axis_array[axis].is_timedata)
 		gstrftime(label, 24, mark->label ? mark->label : ticfmt[axis], mark->position);
 	    else
 		gprintf(label, sizeof(label), mark->label ? mark->label : ticfmt[axis], log10_base, mark->position);
-
-	    (*callback) (axis, internal, label, lgrd);
+	    /* if supplied format is empty, generate unlabeled minitic */
+	    (*callback) (axis, internal, 
+			 mark->label ? (mark->label[0] ? label : 0) : label,
+			 lgrd);
 	}
 
-	return;			/* NO MINITICS FOR USER-DEF TICS */
+	return;
 	/*}}} */
     }
 
--- docs/gnuplot.doc-orig	Sat Apr 12 10:08:42 2003
+++ docs/gnuplot.doc	Sat Apr 12 10:18:53 2003
@@ -4399,9 +4399,11 @@
  the same as `xy`).  The length of the string representing a tic mark (after
  formatting with 'printf') is restricted to 100 characters.  If the format
  string is omitted, the format will be returned to the default "%g".  For
- LaTeX users, the format "$%g$" is often desirable.  If the empty string "" is
- used, no label will be plotted with each tic, though the tic mark will still
- be plotted.  To eliminate all tic marks, use `unset xtics` or `unset ytics`.
+ LaTeX users, the format "$%g$" is often desirable.  If the format has
+ only a space " ", no label will be plotted with each tic, though the
+ tic mark will still be plotted.  An empty string "" will result in an
+ unlabeled minitic.  To eliminate all tic marks, use `unset xtics` or
+ `unset ytics`.
 
  Newline (\n) is accepted in the format string.  Use double-quotes rather than
  single-quotes to enable such interpretation.  See also `syntax`.
@@ -7861,9 +7863,11 @@
  non-numeric tic labels.  A set of tics is a set of positions, each with its
  own optional label.  Note that the label is a string enclosed by quotes.  It
  may be a constant string, such as "hello", may contain formatting information
- for converting the position into its label, such as "%3f clients", or may be
- empty, "".  See `set format` for more information.  If no string is given,
- the default label (numerical) is used.  In this form, the tics do not need to
+ for converting the position into its label, such as "%3f clients".  To get an
+ unlabeled minitic, use an empty string, "".  For an unlabeled normal
+ size tic, use a string with a space " ".  If no string is given, the
+ default label (numerical) is used.  See `set format` for more
+ information.  In this form, the tics do not need to
  be listed in numerical order.
 
  Examples:

filledboxes in CGM terminal

[Jim V. Z. <jr...@co...>]

I implemented filledboxes in the CGM terminal.  May I eliminate this
item from the TODO file?  Or, of course, if there's a problem with the
implementation please let me know.

		      - Jim Van Zandt


--- TODO-orig	2002-11-17 20:25:54.000000000 -0500
+++ TODO	2003-12-20 17:20:27.000000000 -0500
@@ -47,9 +47,6 @@
 Amiga:
   -- update its docs from docs/old/README.ami, then delete this file
 
-CGM:
-  -- implement filledboxes
-
 Emx:
   -- update its docs from docs/old/README.emx, then delete this file
 

Re: Contour lines not continuous

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

On Thursday 18 December 2003 17:15, Hans-Bernhard Broeker wrote:
> I've now created a new pair of routines
>
> polyline3d_start()    #may be renamed to *_move()
> polyline3d_next()     #may be renamed to *_vector()
>
> and use those in cntr3d_lines, instead of draw3d_line().=20
   [...]
> Besides the hidden3d limitation, all's looking fine so far.

Just as a point of reference, here are the output sizes of=20
postscript files produces by base 3.8k before your patch,
the current cvs version, and the current cvs version with
my patch for post.trm from the other day.

[47] wc *.ps
 107936  232574  860642 3.8j.ps
  63070  161130  566356 hbb.ps
  44492  133191  430013 hbb+eam.ps

Test command sequence was in each case:
  set term post color dash
  set output '...'
  load 'contours.dem'

I don't know if the patch to post.trm is fully safe,
but in any event this shows that there is some room
left to further optimize the postscript output over
and above the changes you made to the core routines.


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

Re: Fwd: 'x11 prints garbage to stdout on OS/2' solved now the history-bug

[Lars H. <lhe...@us...>]

> After starting gnuplot and 'plot x' I _sometimes_ get:
> 
> Terminal type set to 'pm'
> gnuplot> plot x
> gnuplot> gnuplot>
> 
>   instead of
> 
> Terminal type set to 'pm'
> gnuplot> plot x
> gnuplot>
> 
>   After getting the double (or sometimes triple or even more) prompt the
>  commandline-history no longer works. When entering Cursor-UP I get H
>  instead of the last command, Cursor-Left gives K, Cursor-Right gives M,
>  Cursor-Down gives P and Del gives S
 
 Could this be a case of broken readline library? As in

  http://sourceforge.net/tracker/index.php?func=detail&aid=608874&group_id=2055&atid=102055

Fwd: 'x11 prints garbage to stdout on OS/2' solved now the history-bug

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

----------  Forwarded Message  ----------

Subject: 'x11 prints garbage to stdout on OS/2' solved now the history-bu=
g
Date: Fri, 19 Dec 2003 00:20:46 +0100 (CET)
From: "Franz Bakan" <fb...@gm...>
To: "gnuplot-beta" <gnu...@li...>
Cc: "Petr Mikulik" <mi...@ph...>, "Ethan Merritt" <merritt@u.=
washington.edu>

On Tue, 16 Dec 2003 17:10:28 -0800, Ethan Merritt wrote:
>
>I have added a command line option
>=09gnuplot -nofeedback
>that disables the feedback path which is causing problems.
>This is not an ideal fix, just a work-around.
>There is a corresponding XResource:
>=09gnuplot*feedback:=09off                 (or false)
>
>Please let me know if this successfully bypasses the
>symptoms you saw under os2.

This solves the problem also here  X11 terminal now works
again as desired. Tested with HOBX11 and XFree86-4.3.0.

The only problem on OS/2 that I can see now (and have allways
seen with gnuplot versions later then 3.7 is the
'command-line-history-problem'.
Probably a timing or synchronisation problem.

After starting gnuplot and 'plot x' I _sometimes_ get:

Terminal type set to 'pm'
gnuplot> plot x
gnuplot> gnuplot>

  instead of

Terminal type set to 'pm'
gnuplot> plot x
gnuplot>

  After getting the double (or sometimes triple or even more) prompt the
 commandline-history no longer works. When entering Cursor-UP I get H
 instead of the last command, Cursor-Left gives K, Cursor-Right gives M,
 Cursor-Down gives P and Del gives S

  Example:

Terminal type set to 'pm'
gnuplot> plot x
gnuplot> gnuplot> HKMPS


Backspace-Key is working correct (sometimes I have to hit it twice
to delete the 'HKMPS' characters but the rest of gnuplot works.

following plot or other commands work as desired but cursor-keys
are broken for the rest of the gnuplot session.

When the PM-Window is large, it's more likely that I see the bug.
When the PM-Window is small the bug is more rare.

Any idea what happens and how to resolve this bug?

Franz

Re: Contour lines not continuous

[Hans-Bernhard B. <br...@ph...>]

OK, let me expand on the details...

> The key difference is in graph3d.c:cntr3d_lines() and friends: in 3.7,
> they used clip_move() and clip_vector() to create (optionally
> clipped/broken) polylines.  In 3.8, we use draw3d_line directly, which
> does both a term->move() and term->vector(), usually.

> AFAICS, it was me who did that, as part of the big set of modifications
> done on the "axis branch".

Staring at the modifications in question for a while, I now
found/remembered the actual background of this.  It was me, indeed, and
it was part of the 'axis' branch, but the rationale was different than
I had first thought.

The real problem with the old cntr3d_line code was that it output the
lines in *2D* mode. clip_move() and clip_vector() are 2D functions, and on
top of everything else, they don't really implement the move()/vector()
semantics to create polylines.  Instead, the global flag suppressMove is
used for that.  The problems with that were that contour lines couldn't
be hidden in hidden3d mode, because the routine that drew them didn't
have the necessary 3D information any more.

I've now created a new pair of routines 

polyline3d_start()    #may be renamed to *_move()
polyline3d_next()     #may be renamed to *_vector()

and use those in cntr3d_lines, instead of draw3d_line().  If either the
'palette' line coloring option or hidden3d is in use, it still falls back
to the 3.8 behaviour, though.  Hidden3d just doesn't support polylines at
this time. For paletted lines, polyline support wouldn't make sense
anyway, so no harm done on that end.

Besides the hidden3d limitation, all's looking fine so far.  Some of you
PM3D experts should test this a bit more thoroughly though, so I'm
checking the current state of this in right away.

Happy holy days, y'all...

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Contour lines not continuous

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

On Thursday 18 December 2003 11:12, Ethan Merritt wrote:
>
> The attached quick patch seems to work, but I have not
> tested it on anything other than contours.dem

Oops. One more minor tweak is needed.
The following corrected patch correctly processes the example script
provided on the newsgroup.   In particular, the contour lines near the
plot origin are rendered in dash-dot modes as listed in the figure key.

HOWEVER - it does indeed reveal a problem, or at least a difference,
with the arrow style code as per the comment in post.trm.
Quick test:
=09set term post color dash
=09set output 'bug.ps'
=09load 'arrowstyle.dem'

You will see that the current 3.8k produces solid arrows everywhere,
whereas the patched version produces dotted arrows.

Then again, if you specifically ask for 'set term post dash', is this rea=
lly an error?


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
# This demo script triggers a bug in 3.8j such that contour lines
# do not get rendered with correct dash/dot values
set terminal postscript landscape enhanced color dashed
set pm3d at st
set border 4095
set surface
set samples 25
set isosamples 20
set ticslevel 0
set contour base
set cntrparam bspline
set view 0,0
set nosurface
set key screen 0.15,0.7 title "Contour" Right nobox
set title "surface and pm3d (surface and top) of radial sinc function"
splot [-15:15.01] [-15:15.01] [-0.2:1] \
  sin(sqrt(x**2+y**2)) / sqrt(x**2+y**2)=20


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

Re: Contour lines not continuous

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

On Thursday 18 December 2003 09:27, Hans-Bernhard Broeker wrote:
> In 3.8, we use draw3d_line directly, which
> does both a term->move() and term->vector(), usually.

Two comments:

(1)
In draw3d_line_unconditional(v1,v2,lp,linetype) we have the code lines:
=09term_apply_lp_properties(lp);
=09[...conditional code...]
=09(term->linetype)(linetype);
This can result in setting the line type twice, unnecessarily.

(2)
I believe that the current problem can be fixed in post.trm by checking
the current line properties before setting new ones.

Part of the problem is the following unfortunate hack, which broke a work=
ing
test on unnecessary line interruptions:
#if 0
    /*  In order to make 'PS_linewidth' work properly, I need to comment
     *  this line out.  Especially in combination with the line width
     *  extension of the `set arrow` command this is necessary.
     *  Can we live with that drawback?  (JFi)
     */
    if (PS_linetype_last =3D=3D linetype) return;
#endif

If the 'set arrow' code is causing problems, then let's fix it
there, not in the postscript driver.

The other half of the problem is that PS_linewidth makes no
such check at all.

PS_move and PS_vector look OK to me.

The attached quick patch seems to work, but I have not
tested it on anything other than contours.dem

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

Contour lines not continuous

[Hans-Bernhard B. <br...@ph...>]

Hello, 

some of you may have seen it over in the user list/newsgroup, but I think
this should be addressed here, too:

A user just found a problem with gnuplot-3.8 that has been sitting in
there for quite some time now:  contour lines are now drawn as individual
line segments, where 3.7 managed to long polylines (sometimes *too* long,
leading to its own kind of problems).  That's bad if the line type used is
patterned, because individual segments re-start the pattern each time,
rendering the pattern indecipherable.

The key difference is in graph3d.c:cntr3d_lines() and friends: in 3.7,
they used clip_move() and clip_vector() to create (optionally
clipped/broken) polylines.  In 3.8, we use draw3d_line directly, which
does both a term->move() and term->vector(), usually.

AFAICS, it was me who did that, as part of the big set of modifications
done on the "axis branch".

I guess this will have to be fixed, too, before a 4.0 becomes ready.
Looks like I just found something to do for the holy days.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.