info-gnuplot-beta : Messages : 4972-5001 of 5001

*YOU* can "help terminal x11" by implementing rotated text! Or do X11 people
prefer all labels horizontal?

OS/2 terminal can rotate text, Windows terminal can, so why not X11?

---
Petr Mikulik

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Reply | Messages in this Topic (3)

#4974

From: Hans-Bernhard Broeker <broeker@...>
Date: Tue Jun 26, 2001 3:15 pm
Subject: Re: help x11! (rotated text)

broeker@...

On Tue, 26 Jun 2001, Petr Mikulik wrote:

>
> *YOU* can "help terminal x11" by implementing rotated text! Or do X11 people
> prefer all labels horizontal?
>
> OS/2 terminal can rotate text, Windows terminal can, so why not X11?

Because, as surprising as that may be, X11 itself doesn't support rotated
text, either. That places supporting rotated text into a whole different
ballpark for X11, compared to other GUI platforms.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Reply | Messages in this Topic (3)

#4975

From: Petr Mikulik <mikulik@...>
Date: Tue Jun 26, 2001 5:39 pm
Subject: Re: help x11! (rotated text)

mikulik@...

> > *YOU* can "help terminal x11" by implementing rotated text! Or do X11 people
> > prefer all labels horizontal?
> > OS/2 terminal can rotate text, Windows terminal can, so why not X11?
> Because, as surprising as that may be, X11 itself doesn't support rotated
> text, either. That places supporting rotated text into a whole different
> ballpark for X11, compared to other GUI platforms.

I know that the (very old design?) API of X11 does not allow rotating text
as simply as one more option somewhere in an API call. But printing to a
bitmap and its subsequent rotation should be pretty easy for X11 programmers
to code (...Xfig et al can rotate text!). This email is an alarm to
volunteers!

Another contest for X11 programmers: making the X11 protocol binary --- gain
a lot of speed.

I think there are many X11 / Unix / Linux users and programmers on this
list, so somebody could organize implementation of the above-mentioned
tasks?

You know, I have a lot of ideas, but I can implement only a few of them...

---
Petr Mikulik




[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Reply | Messages in this Topic (3)

#4976

From: Hans-Bernhard Broeker <broeker@...>
Date: Tue Jun 26, 2001 6:01 pm
Subject: Re: x1 x2 axes do not match

broeker@...

[Taking this over to gnuplot-beta...]

On Tue, 26 Jun 2001, Hans-Bernhard Broeker wrote:

> On Tue, 26 Jun 2001, Thomas Cabela wrote:
>
> > the x1 and x2 tics do not match as you can see if you make the plot
> > below.
>
> Well --- a big part of the problem is that there is absolutely nothing in
> the whole plot that would define the x2range properly.  You don't use the
> x2 axis for anything but placing tics, manually.

Lemme explain the gore details. The problem is one that has been noticed
before. It's a complication caused by auto-extension of autoscaled axis
endpoints to an integer multiple of the tic step, in order to always have
the axis start and end at a "nice" position, rather than in the middle of
nowhere.

What happened is that the xrange was auto-determined to be [5:100], then
it was copied over to the x2range. Later, the xrange was auto-extended
[0:100], but the x2range was not.

> You made it even harder by manually specifying x2tics but no x2range.
> Without the explicit tic position list, I get a correct plot.

This is because due to the explicit list of tic positions in the example
script, gnuplot doesn't do the automatic tic placement algorithm, and thus
sees no need to auto-extend the axis to fit with such auto-tics.  IOW it
assumes that a user who overrode the default tic placement must be knowing
what (s)he's doing, and thus doesn't meddle with the axis endpoints,
either.

So, question to the developers: should we change this?  And if so: how?
Avoid axis extension iff the 'other' axis is unused, but does have an
explicit tic listing? Feels wrong, to me. Can we delay the range-copying
stuff until after the tic extension is done?

The most general solution I could think of would be to abandon the current
attempt of 'magically' creating a useable x2 axis altogether. Instead, a
new feature could be implemented, letting users specify a strict mapping
between x1 and x2 axis. Something like:

	 radtodeg(x)=x*180.0/pi
	 set axismapping x2 radtodeg(x)
	 set xlabel 'angle [radians]'
	 set x2label 'angle [degrees]'
	 plot 'datafile' u 1:2 t 'angular dependence'

This would set up x2 as a 'dependent axis', and the x2 range would be
fixed after all x1 axis tweaking is done, to x2min=radtodeg(x1min),
x2max=radtodeg(x1max). For a situation like the original poster's one,
you would then

	 set axismapping x2 x

(the identity mapping).

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4977

From: Petr Mikulik <mikulik@...>
Date: Tue Jun 26, 2001 7:41 pm
Subject: Re: x1 x2 axes do not match

mikulik@...

I usually use something like

	 f(x) = ...
	 xfrom=1; xto=11;
	 set xrange [xfrom:xto]; set x2range [f(xfrom):f(xto)]
	 plot g(x)

and it works even with mouse zooming
(oops... it reverts x2range if f(zoomed xfrom) > f(zoomed xto) ... who fixes
this? me? with pleasure when x11 can rotate boxes :-))


> endpoints to an integer multiple of the tic step, in order to always have
> the axis start and end at a "nice" position, rather than in the middle of
> nowhere.

I've many times needed that gnuplot uses true "min" and "max" autoscale
values, and not those rounded. There is no option to switch this behaviour,
it seems. I would really enjoy
	 set autoscale x noround    (nojump, closest, nowhere,...)

What option do you vote for / propose? Or is it already in?


> new feature could be implemented, letting users specify a strict mapping
> between x1 and x2 axis. Something like:
>  radtodeg(x)=x*180.0/pi
>  set axismapping x2 radtodeg(x)
> This would set up x2 as a 'dependent axis', and the x2 range would be
> fixed after all x1 axis tweaking is done, to x2min=radtodeg(x1min),
> x2max=radtodeg(x1max).

Does not my approach do exactly this? At least for lin and log axes?

---
Petr Mikulik


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4978

From: Hans-Bernhard Broeker <broeker@...>
Date: Wed Jun 27, 2001 9:30 am
Subject: Re: x1 x2 axes do not match

broeker@...

On Tue, 26 Jun 2001, Petr Mikulik wrote:

> I usually use something like
>
>  f(x) = ...
>  xfrom=1; xto=11;
>  set xrange [xfrom:xto]; set x2range [f(xfrom):f(xto)]
>  plot g(x)

Right. As I said: a large part of the problem was that he did *not*
specify any x2range at all. But this technique has a drawback, too:
it needs knowledge about xfrom and xto at the time the ranges are defined
--- i.e. it doesn't work with autoscaled plots made from (partly) unknown
datafiles.

> and it works even with mouse zooming
> (oops... it reverts x2range if f(zoomed xfrom) > f(zoomed xto) ...

So what? The whole method only works sensibly for linear mappings between
x1 and x2 anyway. Possibly for pow()/log() mappings, too, if you set one
of the two axes to logarithmic. But for all other cases, the tics in the
middle of the x2 axis will be placed incorrectly. And for linear mappings
with a negative slope, reverting the x2 axis is exactly the correct thing
to do.

Even in the generalization approach I proposed, the mapping function still
has to be strictly monotonous and continuous, i.e. invertible, to make
sense. Otherwise, a given input range wouldn't map onto a well-defined
range on the other axis.

> it seems. I would really enjoy
>  set autoscale x noround    (nojump, closest, nowhere,...)
>
> What option do you vote for / propose? Or is it already in?

Might be useful, yes.  But nothing like that's in.  The easiest approach
for implementing it would be to define some more bits in the t_autoscale
bitmap I invented recently. setup_tics() could then look at those bits,
rather than AUTOSCALE_MAX / AUTOSCALE_MIN to determine its local booleans
'fixmin' and 'fixmax'.

> Does not my approach do exactly this? At least for lin and log axes?

Yes. But only for those. I was trying to be as general as possible, on the
principle of "once we do start meddling with this, we might just as well
do it thoroughly, so we won't have to touch it again, soon".

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4979

From: Petr Mikulik <mikulik@...>
Date: Wed Jun 27, 2001 9:57 am
Subject: Re: x1 x2 axes do not match

mikulik@...

> > and it works even with mouse zooming
> > (oops... it reverts x2range if f(zoomed xfrom) > f(zoomed xto) ...
> So what? The whole method only works sensibly for linear mappings between

Yes, I've spotted the problem on this mapping:
	 energy(wavelength) = 12398 / wavelength

I'll fix it (later).

> > it seems. I would really enjoy
> >  set autoscale x noround    (nojump, closest, nowhere,...)
> Might be useful, yes.  But nothing like that's in.  The easiest approach
> for implementing it would be to define some more bits in the t_autoscale
> bitmap I invented recently. setup_tics() could then look at those bits,
> rather than AUTOSCALE_MAX / AUTOSCALE_MIN to determine its local booleans
> 'fixmin' and 'fixmax'.

I would be very pleased if you can implement this. Thanks.

> Yes. But only for those. I was trying to be as general as possible, on the
> principle of "once we do start meddling with this, we might just as well
> do it thoroughly, so we won't have to touch it again, soon".

I think I would like the mapping method you have proposed.

---
Petr Mikulik



[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4980

From: Jonathan Thornburg <jthorn@...>
Date: Thu Jun 28, 2001 10:35 am
Subject: postscript terminal colors != test plot

jthorn@...

Using either of two recent CVS versions of gnuplot,
         Version 3.8e patchlevel 1
         last modified Mon Dec 18 09:25:03 CET 2000
         System: Linux 2.2.19-6.2.1smp
or
         Version 3.8f patchlevel 0
         last modified Thu May 31 18:21:08 CEST 2001
         System: Linux 2.4.2-SGI_XFS_1.0
the colors produced by the postscript terminal don't match those
for the 'test' plot:

gnuplot> set term postscript landscape color solid
Terminal type set to 'postscript'
Options are 'landscape noenhanced color colortext \
    solid dashlength 1.0 linewidth 1.0 defaultplex \
    "Helvetica" 14'
gnuplot> set output 'test.color.solid.ps'
gnuplot> test
gnuplot> set output
gnuplot> set output 'bug.ps'
gnuplot> plot sin(x) with points pointtype 7 pointsize 0.5
gnuplot> set output

'test' says that pointtype 7 should be a solid black circle (see
attached postscript file 'test.color.solid.ps'), while the actual
plot command produces solid red circles (see attached postscript
file 'bug.ps').

We've discussed before ways of allowing independent choice of point
shape and color, but I think this behavior in the present code is
arguably a bug.  But I'm not quite sure whether it should be called
a bug in the 'test' output, a bug in the color choice itself, or a
bug in how we've documented this in the 'plot with' online help output,
> Syntax:
>       with <style> { {linestyle | ls <line_style>}
>                      | {{linetype | lt <line_type>}
>                         {linewidth | lw <line_width>}
>                         {pointtype | pt <point_type>}
>                         {pointsize | ps <point_size>}} }
>
> [[...]]
>
> If you wish to choose the line or point type for a single plot, <line_type>
> and <point_type> may be specified.  These are positive integer constants (or
> expressions) that specify the line type and point type to be used for the
> plot.  Use `test` to display the types available for your terminal.

Ideas?

--
-- Jonathan Thornburg <jthorn@...>
    http://www.thp.univie.ac.at/~jthorn/home.html
    Universitaet Wien (Vienna, Austria) / Institut fuer Theoretische Physik
    "It's every man for himself, said the elephant as he danced on the
     anthill!" -- T. C. "Tommy" Douglas's description of ((you guess))

#4981

From: Hans-Bernhard Broeker <broeker@...>
Date: Thu Jun 28, 2001 11:42 am
Subject: Re: postscript terminal colors != test plot

broeker@...

On Thu, 28 Jun 2001, Jonathan Thornburg wrote:

> the colors produced by the postscript terminal don't match those
> for the 'test' plot:

They do, once you understand the concept of what controls what, in a plot:

> gnuplot> plot sin(x) with points pointtype 7 pointsize 0.5

This will plot the points in *linetype* 1, pointtype 7. The sample in the
'test' page, however, is in some other linetype (0 or -1, I guess).

> We've discussed before ways of allowing independent choice of point
> shape and color, but I think this behavior in the present code is
> arguably a bug.

I'm not quite that certain. The behaviour is at least partly caused by you
not specifying the color (i.e. linetype) at all, so gnuplot picked its
own.

> But I'm not quite sure whether it should be called a bug in the 'test'
> output,

If a bug at all, it's in 'test', right. It doesn't seem to set linetypes
for the points, as a 'plot' would.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4982

From: Jonathan Thornburg <jthorn@...>
Date: Thu Jun 28, 2001 11:58 am
Subject: postscript terminal colors != test plot

jthorn@...

Using
         G N U P L O T
         Version 3.8e patchlevel 1
         last modified Mon Dec 18 09:25:03 CET 2000
         System: Linux 2.2.19-6.2.1smp
the colors produced by the postscript terminal don't match those
for the 'test' plot:

% gnuplot

         G N U P L O T
         Version 3.8e patchlevel 1
         last modified Mon Dec 18 09:25:03 CET 2000
         System: Linux 2.2.19-6.2.1smp

         Copyright(C) 1986 - 1993, 1999, 2000
         Thomas Williams, Colin Kelley and many others

         This is a pre-version of gnuplot 4.0. Please refer to the documentation
         for command syntax changes. The old syntax will be accepted throughout
         the 4.0 series, but all save files use the new syntax.

         Type `help` to access the on-line reference manual
         The gnuplot FAQ is available from
                 http://www.gnuplot.org/faq/

         Send comments and requests for help to <info-gnuplot-beta@...>
         Send bugs, suggestions and mods to <info-gnuplot-beta@...>


Terminal type set to 'x11'
gnuplot> set term postscript landscape color solid
Terminal type set to 'postscript'
Options are 'landscape noenhanced color colortext \
    solid dashlength 1.0 linewidth 1.0 defaultplex \
    "Helvetica" 14'
gnuplot> set output 'test.color.solid.ps'
gnuplot> test
gnuplot> set output
gnuplot> set output 'bug.ps'
gnuplot> plot sin(x) with points pointtype 7 pointsize 0.5
gnuplot> set output
gnuplot>
%

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4983

From: Jonathan Thornburg <jthorn@...>
Date: Thu Jun 28, 2001 12:54 pm
Subject: Re: postscript terminal colors != test plot

jthorn@...

[[About 50 minutes ago I mistakenly sent a mangled duplicate
	 copy of my original message to the mailing list.  My
	 apologies for the duplicate; you can just ignore it.]]

I wrote
| the colors produced by the postscript terminal don't match those
| for the 'test' plot:
| [[...]]
| gnuplot> plot sin(x) with points pointtype 7 pointsize 0.5

Hans-Bernhard Broeker <broeker@...> replied
# They do, once you understand the concept of what controls what, in a plot:
# [[...]]
# This will plot the points in *linetype* 1, pointtype 7. The sample in the
# 'test' page, however, is in some other linetype (0 or -1, I guess).

| We've discussed before ways of allowing independent choice of point
| shape and color, but I think this behavior in the present code is
| arguably a bug.  But I'm not quite sure whether it should be called
| a bug in the 'test' output, a bug in the color choice itself, or a
| bug in how we've documented this in the 'plot with' online help output,

# I'm not quite that certain. The behaviour is at least partly caused by you
# not specifying the color (i.e. linetype) at all, so gnuplot picked its
# own.
# [[...]]
# If a bug at all, it's in 'test', right. It doesn't seem to set linetypes
# for the points, as a 'plot' would.

I was in fact able to get the effect I wanted (solid black circles)
by plotting 'with points linetype 7 pointtype 7 pointsize 0.5'.
But I only knew to try this from rereading my archives of our past
discussions on this mailing list -- I certainly didn't see anything
in 'help plot with' that suggests that this is possible.

At a minimum, I think we should explicitly document under 'help style'
the fact that for some terminals, when using the 'points' style (and
maybe others too???), 'linetype' actually controls point *color*.  We
might should also say that this defaults to being the same as pointtype,
but (for some terminals) can also be varied independently.

We might also want to add to 'help test' a note that it uses the default
settings for everything except the linetype and pointtype, and saying to
see 'help plot with' or 'help style' for details.

--
-- Jonathan Thornburg <jthorn@...>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany             http://www.thp.univie.ac.at/~jthorn/home.html
    "Washing one's hands of the conflict between the powerful and the
     powerless means to side with the powerful, not to be neutral."
                                       -- quote by Freire / poster by Oxfam

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4984

From: Hans-Bernhard Broeker <broeker@...>
Date: Thu Jun 28, 2001 1:14 pm
Subject: Re: postscript terminal colors != test plot

broeker@...

On Thu, 28 Jun 2001, Jonathan Thornburg wrote:

[...]

> I was in fact able to get the effect I wanted (solid black circles)
> by plotting 'with points linetype 7 pointtype 7 pointsize 0.5'.
> But I only knew to try this from rereading my archives of our past
> discussions on this mailing list -- I certainly didn't see anything
> in 'help plot with' that suggests that this is possible.

The problem is that this knowledge is spread over more than 1 "help"
node, I'd say.

> At a minimum, I think we should explicitly document under 'help style'
> the fact that for some terminals, when using the 'points' style (and
> maybe others too???), 'linetype' actually controls point *color*.

I don't think that would be a good way of describing it. Point symbols are
part of a plot, and the plot has a linetype --- that much is documented
clearly, I think. What does seem to be undocumented is that on
color-capable terminals, linetype is effectively the color. I think
we may need a node "linetype" somewhere in the docs --- maybe as a subnode
of "help style" or "help plot with" (those two are the same, anyway :-).

The conclusion that if anything is to influence the color of a point
symbol, it must be the linetype used by that plot shouldn't be too hard.

> We might should also say that this defaults to being the same as
> pointtype, but (for some terminals) can also be varied independently.

pointtype is not by default the same as linetype, nor vice versa. The
default rather is that if you don't specify one of them, gnuplot will
choose one, by automaticaaly increasing the last-used number. If you
specify neither, they'll both increase in parallel --- and only in that
case, they'll be the same, automatically.

> We might also want to add to 'help test' a note that it uses the
> default settings for everything except the linetype and pointtype,

That doesn't need explaining, I think: it's rather obvious that if you
want to make a display of the mapping between numbers and their
correspending line- and pointtypes, there's no way you can do that by
doing it all in the default types.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4985

From: Jonathan Thornburg <jthorn@...>
Date: Thu Jun 28, 2001 2:02 pm
Subject: Re: postscript terminal colors != test plot

jthorn@...

JT| I was in fact able to get the effect I wanted (solid black circles)
JT| by plotting 'with points linetype 7 pointtype 7 pointsize 0.5'.
JT| But I only knew to try this from rereading my archives of our past
JT| discussions on this mailing list -- I certainly didn't see anything
JT| in 'help plot with' that suggests that this is possible.

HBB# The problem is that this knowledge is spread over more than 1 "help"
HBB# node, I'd say.

HBB# Point symbols are
HBB# part of a plot, and the plot has a linetype --- that much is documented
HBB# clearly, I think.

Until earlier this year I had just assumed that linestyle, linetype,
and linewidth were all no-ops (i.e. silently ignored) for the 'points'
style.  It was only our last discussion of this on the mailing list
that showed me the error of this -- I don't think the docs currently
say anything to discourage this assumption.  (And I suspect many other
users have been making it: it's a pretty reasonable assumption that
matches the obvious mental model, that "irrelevant" attributes are
just not used.)

What I'd really like would be for the docs to state explicitly the
effects of each of the style attributes (linestyle, linetype, linewidth,
pointtype, and pointsize), in each of the supported styles.  (Obviously
with a caveat that not all terminals may support all the attributes.)

If this is too much work to document, we could at least start with the
most basic styles: lines, points, linespoints.



HBB# What does seem to be undocumented is that on
HBB# color-capable terminals, linetype is effectively the color.

Yes, we definitely need to document this!



JT| We might should also say that this defaults to being the same as
JT| pointtype, but (for some terminals) can also be varied independently.

HBB# pointtype is not by default the same as linetype, nor vice versa. The
HBB# default rather is that if you don't specify one of them, gnuplot will
HBB# choose one, by automaticaaly increasing the last-used number. If you
HBB# specify neither, they'll both increase in parallel --- and only in that
HBB# case, they'll be the same, automatically.

You're right, I was confused there.



JT|  We might also want to add to 'help test' a note that it uses the
JT|  default settings for everything except the linetype and pointtype,

HBB# That doesn't need explaining, I think: it's rather obvious that if you
HBB# want to make a display of the mapping between numbers and their
HBB# correspending line- and pointtypes, there's no way you can do that by
HBB# doing it all in the default types.

Yes.  What I should have said is that we need to make it clear that
gnuplot actually supports a lot more point type/color combinations
than 'test' shows.  (gnuplot supports a full 2-D point (type,color)
space, but 'test' just shows the diagonal where type=color, i.e.
type 1 color 1, type 2 color 2, type 3 color 3, etc.)

Perhaps the 'help test' node, which currently says
> `test` creates a display of line and point styles and other useful things
> appropriate for the terminal you are using.
should say something more like
   `test` creates a display showing selected line and point styles and other
   useful things appropriate for the terminal you are using.

We could also add some more text to the labels for the lines running
down the right side of the test plot to make it clearer what's going
on:  Instead of marking the individual lines/points with just integers,
we could mark them with the full style specification, eg
      linetype 17 linestyle 17 pointtype 17
[I suppose we could go on to mark the linewidth and pointsize, but
these are probably less critical because they're obviously the same
for all the lines/points in question.]

--
-- Jonathan Thornburg <jthorn@...>
    Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
    Golm, Germany             http://www.thp.univie.ac.at/~jthorn/home.html
    "The first strike in the American Colonies was in 1776 in Philadelphia,
     when [...] carpenters demanded a 72-hour week." -- Anatole Beck

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4986

From: Hans-Bernhard Broeker <broeker@...>
Date: Thu Jun 28, 2001 2:28 pm
Subject: Re: postscript terminal colors != test plot

broeker@...

On Thu, 28 Jun 2001, Jonathan Thornburg wrote:

> What I'd really like would be for the docs to state explicitly the
> effects of each of the style attributes (linestyle, linetype, linewidth,
> pointtype, and pointsize), in each of the supported styles.

There is no real need for that, since this support is not actually
dependent upon the plot style directly, anyway. The plot style just
determines *whether* there are lines and/or points to be drawn.  Then the
linetype and pointtype determine *how* they're drawn. Technically spoken,
the two settings are "orthogonal".

[... documenting `test']
> Yes.  What I should have said is that we need to make it clear that
> gnuplot actually supports a lot more point type/color combinations
> than 'test' shows.  (gnuplot supports a full 2-D point (type,color)
> space, but 'test' just shows the diagonal where type=color, i.e.
> type 1 color 1, type 2 color 2, type 3 color 3, etc.)
[...]

Good idea. Maybe something like this would do:

    `test` outputs a testing and reference page for the current terminal
    driver.  It tests and shows off many features of a terminal: what
    kinds of text formatting it supports, whether it can rotate text,
    what its default font looks like, and some more.

    Thers is also a table showing a selection of linetypes and pointtypes
    available on this terminal, formatted like the key of a normal plot.
    For every number <i> given in the table, a sample line and a point
    symbol are drawn, using the combination of linetype <i> and pointtype
    <i>. In your own plots, you can combine these more freely.

Comments? Stylistic points from our native English speaking readers?

> We could also add some more text to the labels for the lines running
> down the right side of the test plot to make it clearer what's going
> on:  Instead of marking the individual lines/points with just integers,
> we could mark them with the full style specification, eg
>      linetype 17 linestyle 17 pointtype 17

Too long --- this may not fit into the available space, if a rather large
font is used.  And mentioning 'linestyle' in there would even be
misleading.

But the test page sure could do with demonstrations showing whether or not
the terminal supports changing the linewidth and pointsize.  The 'test'
page has never been updated since the days of 3.5, I think, so it doesn't
reflect any of the new features added, since.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4987

From: "Info" <info@...>
Date: Fri Jun 29, 2001 9:09 am
Subject: [�Ұ�] NetPIMS 1.0 - �� ٲ㺸�ʽÿ�.

info@...

�츮 �ǹ�� AutoCAD �ڵ� �� ڵ�ȭ AutoPLOT 5.0
�� ϰ� �� Internet �˻� Internet Search 4.0(��)

�ȳ��Ͻʴϱ�? info-gnuplot-beta��.

�׵�� е�� ɼӿ�� ߵǾ�� NetPIMS 1.0�� info-gnuplot-beta�Բ�� ְ� �Ǿ��ϴ�.

�ֻ�� ȯ��, 1:1 ��, ��, ȫ�� Email, E-Card, SMS �뷮 �� ȯ��, DM �� μ⸦ �� ̺�, �� μ⿡ �̸�� ǹ��̰� �ǿ�� ɵ�� NetPIMS�� ʽÿ�.

�̹� �� ̽� � ��Ϳ�� Ͽ� �� Ȱ�뵵�� ش�ȭ��ų �� ֽ��ϴ�.

�� , �� ʾ� �ѹ� �ռ� �ִ� ��ϸ� �߰��ϰ� �� Դϴ�. �� ð� �� Ʋ�� Ż�� ʽÿ�.

�׻� �ǰ��Ͻñ� �� info-gnuplot-beta�� �� ճ�� Բ� �ϱ� ��մϴ�.
��մϴ�.

NetPIMS �ֿ� �� | �� ٿ�ε� | �� | �� ź�

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4988

From: "William D. Kirby" <wdkirby@...>
Date: Fri Jun 29, 2001 11:43 am
Subject: Hidden3D crash in WIN32 and PM3D

wdkirby@...

The following part of the pm3d demo.gp fails in a Win32 build with
Cygwin v1.3.2
when a hidden3d command is used. Failure meaning complete crash on a
Windows NT 4.0 SP3.
The Cygnus build for the X11 system (i.e., the better Windows system)
works fine.
Without the hidden3d command the output looks the same as given by the
X11 version
except there is no hidden3d feature. The following script will crash
with the hidden3d command active.

set title "color lines: 'splot sin(y)/(y) with linesp lt pal'"
set ticslevel 0
set border 4095
set xrange [-10:10]; set yrange [-10:10]
#set hidden3d
set isosamples 40,40; set samples 40,40
splot sin(y)/(y) w lp lt pal
pause -1

Everything before and following this part works fine in demo.gp.


[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Reply | Messages in this Topic (2)

#4989

From: Hans-Bernhard Broeker <broeker@...>
Date: Fri Jun 29, 2001 12:56 pm
Subject: Re: Hidden3D crash in WIN32 and PM3D

broeker@...

On Fri, 29 Jun 2001, William D. Kirby wrote:

> The following part of the pm3d demo.gp fails in a Win32 build with
> Cygwin v1.3.2 when a hidden3d command is used. Failure meaning
> complete crash on a Windows NT 4.0 SP3. The Cygnus build for the X11
> system (i.e., the better Windows system) works fine.

Hmm.... I'm not sure it's the actual reason for the crash you saw (no
Win32 system near me to check this on), but using that script on
a 64bit Unix machine triggered a SIGFPE crash as soon as I rotated
the plot around with the mouse... I dug into it and found that PM3D's
special vertex field "real_z" was not always set up properly. I'm
checking in a fix against that, right now.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

Reply | Messages in this Topic (2)

#4990

From: "James R. Van Zandt" <jrv@...>
Date: Sat Jun 30, 2001 8:18 pm
Subject: "fence" plots

jrv@...

Hans-Bernhard -

Thank you very much for your ideas on creating what you call a "fence"
plot.  I decided it was sufficiently non-obvious that it should be
included in the demos, so I just added a couple of plots to
demo/suface1.dem.  I made several other changes while I was at it,
including adding a PM3D plot.

	     - Jim Van Zandt

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4991

From: Hans-Bernhard Broeker <broeker@...>
Date: Tue Jul 3, 2001 1:11 pm
Subject: Re: x1 x2 axes do not match

broeker@...

On Wed, 27 Jun 2001, Petr Mikulik wrote:

> > > it seems. I would really enjoy
> > >  set autoscale x noround    (nojump, closest, nowhere,...)
[...]

> I would be very pleased if you can implement this. Thanks.

OK. Done it. The new settings are called:

	 set autoscale x2fixmin

and friends.

I'll put the full-scale coupled-axes stuff on the back-burner. It's going
to SourceForge as an Open Task.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4992

From: Hans-Bernhard Broeker <broeker@...>
Date: Tue Jul 3, 2001 5:05 pm
Subject: Re: PS Output Errors in 3.8f

broeker@...

[Note: redirecting this to the developers' mailing list, where bug
reports about the development version are supposed to go, rather than
the users' mailing list / newsgroup]

In article <3B41E0C5.FC87DB41@...> you wrote:

>   1.  Using ghostview/PS-printer on the individual file...no problem
>   2.  Using ghostview/PS-printer on LaTeX/dvips generated file including
> these figures fails at the end of rendering the 3.8f file.

Fails *how*? Exact error message, please. Even if it looks completely
like gibberish, it may still be useful.

A complete example, including a minimal LaTeX framework and output
that reproduces the problem, for you, would be helpful.

We've had somewhat vague reports stating that the "Symbol-Oblique"
modification to the postscript driver may be the culprit, but no
useable analysis what's wrong with it, yet.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4993

From: Lars Hecking <lhecking@...>
Date: Thu Jul 5, 2001 10:44 am
Subject: Re: autoconf 2.50?

lhecking@...

Alexander Mai writes:
> When running the prepare script to recreate some files I get:
>
>  ./prepare
> autoheader: error: shell error while sourcing /tmp/ahgrzz8e/traces.sh
>
> I'm using autoheader from autoconf 2.50, while 2.13 seems to work.

  It won't work with 2.50.

  2.50 is not compatible with 2.13, and I haven't found a way yet to
  rewrite configure.in so that both versions work.

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4994

From: Alexander Mai <st002279@...>
Date: Thu Jul 5, 2001 12:35 pm
Subject: Re: autoconf 2.50?

st002279@...

On Thu, Jul 05, 2001 at 01:17:00PM +0200, Hans-Bernhard Broeker wrote:

> >  2.50 is not compatible with 2.13, and I haven't found a way yet to
> >  rewrite configure.in so that both versions work.
>
> That would be impossible, I think. I.e. we'll have to require exactly
> *one* of the two.
>
> Looking at the status of things as visible in the gnu.utils.bug newsgroup,
> I think we should leave autoconf 2.50 well alone, for now. It's so
> incompatible to all earlier versions they had better called it 2.95 or
> something, to signal it's really a beta release aiming at an incompatible
> new autoconf 3 coming in from beyond the horizon.

OK, let's agree on 2.13 for now.
We need to document this; at the same place we should also
mention the 'prepare' shell script for gnuplot/CVS users.

BTW, that script suffers from the fact that it's not marked as executable.
IIRC we once had a similar and were not able to solve this.
Shall I remove it and check it in with a different name and correct
permission bits? (e.g. 'Prepare')

--
Alexander Mai
st002279@...

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4995

From: Hans-Bernhard Broeker <broeker@...>
Date: Thu Jul 5, 2001 12:57 pm
Subject: Re: autoconf 2.50?

broeker@...

On Thu, 5 Jul 2001, Alexander Mai wrote:

> BTW, that script suffers from the fact that it's not marked as executable.
> IIRC we once had a similar and were not able to solve this.

We couldn't solve it ourselves, right. Back then, it required SourceForge
personnel's manual intervention to do this (--> file SupportRequest,
wait). By now, I think we should be able to do this ourselves.
I'll see whether that actually works.

> Shall I remove it and check it in with a different name and correct
> permission bits? (e.g. 'Prepare')

No.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4996

From: Hans-Bernhard Broeker <broeker@...>
Date: Thu Jul 5, 2001 11:17 am
Subject: Re: autoconf 2.50?

broeker@...

On Thu, 5 Jul 2001, Lars Hecking wrote:

> Alexander Mai writes:

> > I'm using autoheader from autoconf 2.50, while 2.13 seems to work.
>
>  It won't work with 2.50.
>
>  2.50 is not compatible with 2.13, and I haven't found a way yet to
>  rewrite configure.in so that both versions work.

That would be impossible, I think. I.e. we'll have to require exactly
*one* of the two.

Looking at the status of things as visible in the gnu.utils.bug newsgroup,
I think we should leave autoconf 2.50 well alone, for now. It's so
incompatible to all earlier versions they had better called it 2.95 or
something, to signal it's really a beta release aiming at an incompatible
new autoconf 3 coming in from beyond the horizon.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4997

From: Nigel Nunn <nNunn@...>
Date: Sat Jul 7, 2001 4:59 pm
Subject: Re: MFC Gnuplot // current source

nNunn@...

I have some time to work on an MFC-friendly Visual Studio
Workspace for Gnuplot.  Looks like there have been quite
a few changes since that last snapshot [2001/Apr/11]. Our
firewall still prevents cvs-access.  Can someone please
zip up a another current snapshot of the Gnuplot source
and make it available via ftp, etc?
many thanks!
Nigel

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4998

From: Lars Hecking <lhecking@...>
Date: Sat Jul 7, 2001 5:23 pm
Subject: Re: MFC Gnuplot // current source

lhecking@...

Nigel Nunn writes:
> I have some time to work on an MFC-friendly Visual Studio
> Workspace for Gnuplot.  Looks like there have been quite
> a few changes since that last snapshot [2001/Apr/11]. Our
> firewall still prevents cvs-access.  Can someone please
> zip up a another current snapshot of the Gnuplot source
> and make it available via ftp, etc?
> many thanks!

  I have some changes to configure here that I need to complete
  first. Then I'd commit them and release current as 3.8g some
  time next week, if that's ok.

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#4999

From: Nigel Nunn <nNunn@...>
Date: Sat Jul 7, 2001 6:01 pm
Subject: RE: MFC Gnuplot // current source

nNunn@...

Lars Hecking writes:

> I have some changes to configure here that I need
> to complete first. Then I'd commit them and release
> current as 3.8g some time next week, if that's ok.

Thanks Lars.  In the meantime, if anyone has preferences
for implementing an MFC textwin (ListView/EditView/etc)
now is a fine time to say so.  Using a "textwin" style
command line GUI would be an option to programmatically
sending command-lines via do_line().  Hopefully, we
should also be able to get all of HBB's excellent
WinMousing code to work in a standard MFC CView.
Would an underlying CWnd "PlotPanel" make an MFC
implementation more usable?  This sort of approach
is illustrated in Paul Barvinko's "Graph2D",

http://www.codeproject.com/miscctrl/graph2d.asp

thanks,
Nigel

-----Original Message-----
From: Lars Hecking [mailto:lhecking@...]
Sent: Sunday, July 08, 2001 3:23 AM
To: info-gnuplot-beta@...
Subject: Re: MFC Gnuplot // current source

Nigel Nunn writes:
> I have some time to work on an MFC-friendly Visual Studio
> Workspace for Gnuplot.  Looks like there have been quite
> a few changes since that last snapshot [2001/Apr/11]. Our
> firewall still prevents cvs-access.  Can someone please
> zip up a another current snapshot of the Gnuplot source
> and make it available via ftp, etc?
> many thanks!

  I have some changes to configure here that I need to complete
  first. Then I'd commit them and release current as 3.8g some
  time next week, if that's ok.

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#5000

From: Hans-Bernhard Broeker <broeker@...>
Date: Mon Jul 9, 2001 10:03 am
Subject: RE: MFC Gnuplot // current source

broeker@...

On Sun, 8 Jul 2001, Nigel Nunn wrote:

> Thanks Lars.  In the meantime, if anyone has preferences
> for implementing an MFC textwin (ListView/EditView/etc)
> now is a fine time to say so.

Just to plug the holes in my lossy memory: you do have that MFC version
prepared by that Italian fellow, Amadeo Farello, right? If you don't,
tell me, and I'll send them. They're based on 3.7.1, not the current CVS
version, but otherwise, they seemed to work fine.

> should also be able to get all of HBB's excellent WinMousing code to
> work in a standard MFC CView.

Surely we should.  It's nothing complicated anyway, after all.  If nothing
else helped, you should still be able to get down to the raw iron of the
Windows API, even from within an MFC app.

Anyway: as you please.  Unless I'm very much mistaken, there's little or
no MFC programming knowledge except yours in this whole development team,
so you're essentially on your own. If you need reliable advice, you'll
probably have to get it elsewhere.

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

[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]

#5001

From: "William D. Kirby" <wdkirby@...>
Date: Mon Jul 9, 2001 7:52 pm
Subject: PM3d crash in Cygwin WIN32 version revisited

wdkirby@...

Testing of the Cygwin WIN32 version of the latest cvs snapshot the
following script still causes an access violation. It is taken from the
pm3d demo.gp set.

I reported before that the script works if the hidden3d command was
taken out. Further investigation shows the crash is really associated
with ticslevel command. The crash occurs with the value of 0 or even
0.0, but not with a value of 0.1. Removal of the ticslevel statement
works as well.

set title "color lines: 'splot sin(y)/(y) with linesp lt pal'"
set ticslevel 0
set border 4095
set xrange [-10:10]; set yrange [-10:10]
set hidden3d
set isosamples 40,40; set samples 40,40
splot sin(y)/(y) w lp lt pal
pause -1

BTW the mouse is still required to on the pause command (CR alone does
not work).




[[[[ unsubscribe from info-gnuplot-beta via majordomo@... ]]]]