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

Re: Contour plots

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

Harald Harders wrote:

> Hans-Bernhard, what do you think about my suggestion that the user
> could provide a curve in x-y space (parametric function or data
> points). The labels can then be placed where the given curve and the
> contour lines intersect.
> 
> A syntax could be as follows:
> 
> set cntrparam labels along 3*t, 3*t**2
> set cntrparam labels along 'filename.dat' using 1:2

IMHO, that's exactly the right direction in general.  What I'm worrying 
about are the details.  Like

1) One locus curve only, or several?
2) A label at every intersection, or only every n-th?
3) How to specify the curve[s] (abusing variable 't' feels like almost
certainly the wrong idea...)

I guess while at it, the entire command handling of 'set contour'
would have to undergo a review: 'set clabel' is a dangerously ill-named,
hard-to-find option; 'set contour' and 'set cntrparam' don't really 
deserve being separate commands; and there probably should be a 
"contour axis" with all the usual capabilities (so the contours to be 
used would be selected through 'set ctics' and 'set crange', and labels 
by the difference between minor/major ctics, text to be printed by 'set 
cformat', ...) used by the contouring code.  This would take a large 
part of the load off the shoulders of 'set cntrparam', and possibly make 
it redundant, so the remaining job can be done by 'set contour' alone.

Re: Contour plots

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

Ethan Merritt wrote:
> On Friday 28 January 2005 12:41 am, Hans-Bernhard Broeker wrote:
> 
>>*) I'm strictly against any GUI-only feature.  Once we have a suitable
>>command line method of specifying the locus of those contour labels, we 
>>can think of a mouse interaction method of doing the same.  We may even 
>>have to keep in mind that a GUI should be possible while setting up the 
>>command line syntax.  But command line is still *mandatory*.
> 
> 
> I think you are looking at this from the wrong direction.
> A script to label contout plots is not a "GUI-only feature",
> it is an example of a higher-level application you can build
> on top of gnuplot's core functionality.

I tried to find any way in which this statement of yours disagrees with 
mine, which you seem to be saying it does.  I failed.  I guess we must
have misunderstood each other, so let me expand on what I was trying to 
say here.

My comment was aimed against previous ones which apparently wanted to do 
this as an internal job of the mouse interface (e.g. draw the label 
locus curve with a mouse drag), but didn't mention any way of making the 
result survive the gnuplot session (or even the next plot command).  I'm 
saying I'm strictly against such a plan, just in case anybody is 
seriously considering doing it that way.  OTOH, it would be perfectly 
okay for mouse interaction to generate an ordinary, scriptable and 
savable command, just like the vast majority of the current mouse 
interactions do.

> I suspect that creating a general contour-labelling algorithm is
> hard enough, and speciallized enough, that it does not belong 
> inside gnuplot.  

Well, I don't see anything stopping someone from doing such an a program 
(along with generating the contours themselves, while at it) outside 
gnuplot, right now.  But then, I'm sure I don't grasp all the fine 
details of what the mouse interface can currently do.

Re: Now working on POV-Ray terminal

[KITA T. <t-...@cc...>]

I am very glad to have your comments.
# I am curious about how much interested gnuplot users are in our
# POV-Ray and VRML term.

From: Harald Harders
Subject: Re: Now working on POV-Ray terminal
Date: Sat, 29 Jan 2005 00:39:49 +0100 (CET)

> On Thu, 27 Jan 2005, KITA Toshihiro wrote:
> 
> > I and one of my students, Miyata, are currently working on the
> > POV-Ray and VRML terminal of gnuplot.
> 
> [...]
> 
> > It is just a alpha-version and not so neatly written.
> > Maybe in several weeks we can provide our patch file to add these two
> > terminals here at this ML.
> 
> Just a few comments:
> 
> - Your povray file is buggy. You are using #macro defines and state that
>   you have version 3.0. Please use
>   #version 3.1

Oh, I was always testing files with povray 3.1g. (included in the
Linux distribution called Vine commonly used in Japan)

I just found the latest version of POV-Ray is 3.6.1.
I guess it would be better to write
#version 3.6;

And moreover, warnings like
File: tt1.pov  Line: 58
Parse Warning: Degenerate CSG bounding box (not used!).
...
still remain.

From now on I will use povray 3.6.1 for testing.

> - Have you thought of adding spheres to the end of cylinders? This would
>   make the output much nicer.
> 
> Please try it with my changes:
> 
> --- tt1.pov     2005-01-27 09:21:12.000000000 +0100
> +++ tt1a.pov    2005-01-29 00:38:23.000000000 +0100
> @@ -1,4 +1,4 @@
> -#version 3.0
> +#version 3.1
>  #include "colors.inc"
>  #include "shapes.inc"
>  #include "textures.inc"
> @@ -40,6 +40,13 @@
>  cylinder{<0,12.5,0><50,12.5,0>,0.2}
>  cylinder{<0,25,0><50,25,0>,0.2}
>  cylinder{<0,37.5,0><50,37.5,0>,0.2}
> +sphere{<50,50,-40>,0.5}
> +sphere{<0,0,-40>,0.5}
> +sphere{<0,50,-40>,0.5}
> +sphere{<0,0,0>,0.5}
> +sphere{<0,50,0>,0.5}
> +sphere{<50,50,0>,0.5}
> +sphere{<50,0,0>,0.5}
>  text{ ttf "crystal.ttf","-2",0.1,0
>  pigment{White}
>  scale 4

That is a nice suggestion.
We will change the program according to your suggestion.


Any questions and comments are welcomed. > all
-- 
  KITA Toshihiro
  http://t-kita.net/

Re: %%BoundingBox and %%Orientation in *.ps and *.eps files

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

On Fri, 28 Jan 2005, Ethan Merritt wrote:

> On Friday 28 January 2005 01:53 pm, Harald Harders wrote:
> >
> > How do you want to programme that? The BoundingBox has to be in the header
> > of the Postscript file. It is not allowed to use (atend) here.
>
> Yes it is.  This is explicitly stated in Appendix G of the PostScript
> Language Reference.  It's also pretty common, for obvious reasons.

Oh, sorry, I did not know that. But I am pretty sure that many programmes
will not be able to work with a Postscript file that does not have the
BoundingBox at the beginning of the file. I believe I remember that LaTeX,
for example, only reads the first few lines. I recommend not to use this
feature, although it is allowed.

Mmmh, I do not understand why you say that it's common to use it. Yes, of
course it is handy to write such files; but I cannot remember that I have
ever seen such a file.

Regards
Harald

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

Re: Contour plots

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

Ethan Merritt wrote:

>On Friday 28 January 2005 12:41 am, Hans-Bernhard Broeker wrote:
>  
>
>>*) I'm strictly against any GUI-only feature.  Once we have a suitable
>>command line method of specifying the locus of those contour labels, we 
>>can think of a mouse interaction method of doing the same.  We may even 
>>have to keep in mind that a GUI should be possible while setting up the 
>>command line syntax.  But command line is still *mandatory*.
>>    
>>
>
>I think you are looking at this from the wrong direction.
>A script to label contout plots is not a "GUI-only feature",
>it is an example of a higher-level application you can build
>on top of gnuplot's core functionality.
>  
>

I like the idea, but it seems to me that this is just a tiny step above 
gnuplot.

>I suspect that creating a general contour-labelling algorithm is
>hard enough, and speciallized enough, that it does not belong 
>inside gnuplot.  Instead we should ask ourselves what core functions
>would be needed to allow a higher-level program to be build on top
>of gnuplot. I imagine that to be truly useful, this hypothetical
>program would use a mixture of automated labelling and interactive
>placement or editing.  
>  
>

But any chance of an automated method would need access to the level 
curves generated by the drawing program.  If done outside of gnuplot, 
then there would need to be a first stage of extracting the curves... 
and for that matter, the values associated with the contours would be 
lost to what is built on top of gnuplot... unless of course, it had the 
original data and could reconstruct the level curves... in which case it 
wouldn't need gnuplot's contour functions.

I guess the one strong argument for Gnuplot to be the one to place 
labels would be that without it there is a limitation in the fact that 
Gnuplot's contour plots can't express the level values of the contour in 
black and white.  Grayscale could be used, but that never seems to come 
out looking good.

>The mousing script is an example of how that externally-driven
>interaction may already be supported. I don't know what, if any,
>addition command line options might be needed also. The earlier
>suggestion of letting the user specify a parametric function and
>having gnuplot calculate the intersections with contour lines is
>an interesting start.
>

One of the plots I saw in a dynamics book on the shelf had a nice 
swooping array of labels which makes me think it used a parametric 
function approach.

I'd suspect that some computer science student or group has studied this 
problem.  There must be literature on this problem somewhere.

Dan

Re: %%BoundingBox and %%Orientation in *.ps and *.eps files

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

On Friday 28 January 2005 01:53 pm, Harald Harders wrote:
> 
> How do you want to programme that? The BoundingBox has to be in the header
> of the Postscript file. It is not allowed to use (atend) here.

Yes it is.  This is explicitly stated in Appendix G of the PostScript
Language Reference.  It's also pretty common, for obvious reasons.


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

Re: Now working on POV-Ray terminal

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

On Thu, 27 Jan 2005, KITA Toshihiro wrote:

> I and one of my students, Miyata, are currently working on the
> POV-Ray and VRML terminal of gnuplot.

[...]

> It is just a alpha-version and not so neatly written.
> Maybe in several weeks we can provide our patch file to add these two
> terminals here at this ML.

Just a few comments:

- Your povray file is buggy. You are using #macro defines and state that
  you have version 3.0. Please use
  #version 3.1
- Have you thought of adding spheres to the end of cylinders? This would
  make the output much nicer.

Please try it with my changes:

--- tt1.pov     2005-01-27 09:21:12.000000000 +0100
+++ tt1a.pov    2005-01-29 00:38:23.000000000 +0100
@@ -1,4 +1,4 @@
-#version 3.0
+#version 3.1
 #include "colors.inc"
 #include "shapes.inc"
 #include "textures.inc"
@@ -40,6 +40,13 @@
 cylinder{<0,12.5,0><50,12.5,0>,0.2}
 cylinder{<0,25,0><50,25,0>,0.2}
 cylinder{<0,37.5,0><50,37.5,0>,0.2}
+sphere{<50,50,-40>,0.5}
+sphere{<0,0,-40>,0.5}
+sphere{<0,50,-40>,0.5}
+sphere{<0,0,0>,0.5}
+sphere{<0,50,0>,0.5}
+sphere{<50,50,0>,0.5}
+sphere{<50,0,0>,0.5}
 text{ ttf "crystal.ttf","-2",0.1,0
 pigment{White}
 scale 4


Regards,
Harald

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

Re: Contour plots

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

On Fri, 28 Jan 2005, Hans-Bernhard Broeker wrote:

Hans-Bernhard,

> Daniel J Sebald wrote:
>
> [...]
> > I would too.  However, might it be possible to use some simple
> > algorithm that does an OK job in most cases?
>
> I rather much doubt that such a thing exists.   In contouring, I suspect
> most cases are too tricky for any simple algorithm.
>
> > The worst case scenario is when the contours are rather small oval
> > shapes, or rather close together.  But if it is unacceptable to the
> > user, then he or she could turn off annotation.
>
> We really need better control than just on/off on this.

I also think that it is nearly impossible to find a fully automatic
mechanism to produce contour labels.

Hans-Bernhard, what do you think about my suggestion that the user could
provide a curve in x-y space (parametric function or data points). The
labels can then be placed where the given curve and the contour lines
intersect.

A syntax could be as follows:

set cntrparam labels along 3*t, 3*t**2
set cntrparam labels along 'filename.dat' using 1:2

The variable t should be free since u and v are used for parametric
splots. Using 'set trange' the user can determine in which area of the
plot labels are produced.
With 'set trange [0:100]', for instance, only the first quadrant gets
contour labels in the example above.

> Some other random points:
>
> *) I'm strictly against any GUI-only feature.  Once we have a suitable
> command line method of specifying the locus of those contour labels, we
> can think of a mouse interaction method of doing the same.  We may even
> have to keep in mind that a GUI should be possible while setting up the
> command line syntax.  But command line is still *mandatory*.

I fully agree.

> *) We're going to paint labels in the middle of the data area.  I.e. we
> risk covering up critical aspects of the plotted data, which I consider
> a strict no-no.  That's why a simple on/off control would be
> insufficient.  We can't seriously expect users to accept that if the
> default placement puts on of  a dozen labels in some undesirable place,
> their only option is to give up on in-graph contour labels altogether
> (or roll their own by plotting an extra file 'with labels')

I also fully agree. Using the function described above, this shortcoming
could be avoided since the user has control over the labels. The syntax
could even be enhanced:

Write a label for all contour lines:
set cntrparam labels along 3*t, 3*t**2
set cntrparam labels along 'filename.dat' using 1:2

Write a label for the contour lines 3,4,5,6,7,8:
set cntrparam labels 3,1,8 along 3*t, 3*t**2

Write a label for the contour lines 3,4,5,8:
set cntrparam labels (3, 4, 5, 8) along 3*t, 3*t**2
set cntrparam labels ('less' 3, 4, 5, 'much' 8) along 'filename.dat' using 1:2

> *) In-graph contour labelling must take into account whether a terminal
> can render rotated text or not.  There will be a considerably large
> number of cases where horizontal-only labels are hard or impossible to
> place, while text oriented parallel to the contour line would still work.

That's also correct. Maybe, an option should be provided that decides if
the labels are rotated with the contour or not (if the terminal is capable
to do that):

set cntrparam labels along 3*t, 3*t**2 norotate
set cntrparam labels along 3*t, 3*t**2 autorotate
set cntrparam labels along 3*t, 3*t**2 rotate by 45

Regards
Harald

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

Re: %%BoundingBox and %%Orientation in *.ps and *.eps files

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

On Thu, 27 Jan 2005, Ethan Merritt wrote:

> But in looking this up in the PostScript Reference Manual I also
> notice that there is a distinction between
>
> %%BoundingBox and %%PageBoundingBox
>
> An *eps file should use only %%BoundingBox.  So we're OK there.
>
> But the existence of %%PageBoundingBox seems directly relevant
> to recent discussion on the use of "set size" before and
> after "set term".
>
> I believe that the sequence
>   set size <x>,<y>
>   set term post
> should alter the contents of %%BoundingBox
>
> But the sequence
>   set term post
>   set size <x>,<y>
>   plot "foo"
>   set size <x2>,<y2>
>   plot "baz"
> should in principle be setting %%PageBoundingBox each time
> the size is changed. At the end of the file, %%BoundingBox
> is set to the maximum values ever used for individual pages.
>
> Is it worth making this change?

How do you want to programme that? The BoundingBox has to be in the header
of the Postscript file. It is not allowed to use (atend) here. You have to
know what the BoundingBox of the plot will be before you do the first
plot. Or do you want to hold the whole Postscript file in memory until the
terminal is resetted or output is changed?  I am curious.

Regards
Harald

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

Re: Contour plots

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

On Friday 28 January 2005 12:41 am, Hans-Bernhard Broeker wrote:
> *) I'm strictly against any GUI-only feature.  Once we have a suitable
> command line method of specifying the locus of those contour labels, we 
> can think of a mouse interaction method of doing the same.  We may even 
> have to keep in mind that a GUI should be possible while setting up the 
> command line syntax.  But command line is still *mandatory*.

I think you are looking at this from the wrong direction.
A script to label contout plots is not a "GUI-only feature",
it is an example of a higher-level application you can build
on top of gnuplot's core functionality.

I suspect that creating a general contour-labelling algorithm is
hard enough, and speciallized enough, that it does not belong 
inside gnuplot.  Instead we should ask ourselves what core functions
would be needed to allow a higher-level program to be build on top
of gnuplot. I imagine that to be truly useful, this hypothetical
program would use a mixture of automated labelling and interactive
placement or editing.  

The mousing script is an example of how that externally-driven
interaction may already be supported. I don't know what, if any,
addition command line options might be needed also. The earlier
suggestion of letting the user specify a parametric function and
having gnuplot calculate the intersections with contour lines is
an interesting start.  I don't think you'd want gnuplot itself to
go ahead and place labels at those intersections, but it could
place them into an array of user-accessible coordinates.  The 
hypothetical higher-level application could then inspect the
intersections and choose to write a label there or not based
on how dense they are.


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

Re: Contour plots

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

Hans-Bernhard Broeker wrote:

>
>> Of course, the optimum thing to do is to pick the location on the 
>> level curve that is furthest from it's neighboring level curves.  It 
>> has to work on general data, so gradient or such would be out.  
>
>
> But the discrete gradient wouldn't be.
>
> Remember that contours are based on a grid dataset, which actually has 
> been cut into triangles in the x/y plane.  The contour curve is made 
> from edges cutting through such triangles.  The gradient of the 
> triangle can be used as a reasonable approximation of the surface 
> gradient.


That might be good.  If the minimum gradient were chosen, the locations 
of the annotation (enumeration?) would likely strike out a nice looking 
curve.  However, there would probably have to be a rule that picking 
such a minimum (actually we're talking minimum of the gradient 
magnitude) requires not only the minimum, but an "epsilon tolerance" for 
which to surpass the current gradient magnitude minimum.  Otherwise, for 
simple curves like ellipses, with symmetry, the text might bounce back 
and forth across the curve according to the bit noise of computations.

Dan

Re: Contour plots

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

Daniel J Sebald wrote:
> Hans-Bernhard Broeker wrote:

>> If it's closed, it doesn't really have a starting point, does it?

> Not mathematically, but in the plotting routine it has to start 
> somewhere.

Yes.  But that point is essentially just a random pick.  It has no
geometrical or mathematical relevance.

> But I'm sure the starting point for drawing the curve isn't 
> necessarily the best position.

Exactly.  Actually, it would only ever be so by strong coincidence.

Even a biassed choice like "if in doubt, place the label on the
uppermost point of a closed contour" would be better than the arbitrary
point where the linear list of points is stitched together to form a
closed loop.

> Of course, the optimum thing to do is to pick the location on the 
> level curve that is furthest from it's neighboring level curves.  It 
> has to work on general data, so gradient or such would be out.  

But the discrete gradient wouldn't be.

Remember that contours are based on a grid dataset, which actually has 
been cut into triangles in the x/y plane.  The contour curve is made 
from edges cutting through such triangles.  The gradient of the triangle 
can be used as a reasonable approximation of the surface gradient.

multi byte patch for x11 terminal

[Shigeharu T. <sh...@ie...>]

shige 01/28 2005
----------------

I made patches for using multi byte fonts in x11 terminal, by 
modifying the patch code included in Yamaga's gnuplot+ patch. He
kindly accepted to use it and hoped it will be included in 
gnuplot-current CVS tree.

The patches are the followings:

 http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/gplt-mbfont9.diff
 http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/data/gplt-mbfont10.diff

The two patches are almost the same, but the latter one uses 
wrapper functions absorbing the differences of treating single 
byte fonts and multi byte fonts.

Under the patch the multi byte extension is done in gnuplot by 
specifying the prefix "mbfont:" on the font name. For example,

 set term x11 font 'mbfont:kana14;k14'
 # "kana14" is alias name of a single byte font "*-jisx0201.1976-0",
 # "k14" is of multi byte font "*-jisx0208.1983-0",
 # and ';' is the separator of font names.

 set term x11 font 'mbfont:fixed,16,r,medium'
 # the patch also support <font>,<size>,<slant>,<weight> form

Since it uses the function XmbDrawString() which require 
setlocale() and XLOCALE, I think the feature should be enable if 
the option like "--enable-x11-multibyte" is specified to the 
configure script for the definition of "USEXMULTIBYTE".

The multi byte extension is not only for Japanese, I tested it on
some multi byte locales: 
 ja_JP.EUC (Japanese), ko_KR.EUC (Korean), zh_CN.EUC (Chinese). 
It seems to work fine under the appropriate locale setting (for 
example, "setenv LC_ALL ko_KR.EUC").

The function XmbDrawString() use XFontSet which includes several 
fonts:
 for ja_JP.EUC:
  *-jisx0201.1976-0 (single byte font)
  *-jisx0208.1983-0 (multi byte font)
 for ko_KR.EUC:
  *-ksc5636-0 or *-iso8859-1 (single byte font)
  *-ksc5601.1987-0 (multi byte font)
 for zh_CN.EUC:
  *-gb1988.1989-0 or *-iso8859-1 (single byte font)
  *-gb2312.1980-0 (multi byte font)

So, we need the separator ';' to specify several font names and
could not realize by using gnuplot's feature 'set encoding'.

Some sample scripts and images are on the following page (but,
the page is written in Japanese, sorry):

 http://takeno.iee.niit.ac.jp/~shige/unix/gnuplot/gnuplot.html

The patch also supports two special font names "Ryumin-Light"
and "GothicBBB-Medium" (the advice from N.Matsuda) which are the
Japanese standard PostScript font names. These fonts can be used
without the prefix "mbfont:".

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Contour plots

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

Hans-Bernhard Broeker wrote:

> Daniel J Sebald wrote:
>
> [...]
>
>> I would too.  However, might it be possible to use some simple 
>> algorithm that does an OK job in most cases?
>
>
> I rather much doubt that such a thing exists.   In contouring, I suspect
> most cases are too tricky for any simple algorithm.


I suppose.  With a straight line you could cover ovals.  (Annotation 
only for ovals!  That'd go over big.)

>> The worst case scenario is when the contours are rather small oval
>> shapes, or rather close together.  But if it is unacceptable to the
>> user, then he or she could turn off annotation.
>
>
> We really need better control than just on/off on this.
>
>> Rather than an optimization problem where we, say, pick a trajectory
>> with the smallest gradient (i.e., largest spacing between contours),
>> could we just pick some line for which to intersect as the spot to
>> pick the label text?  (Intersecting with lines is a not so difficult
>> thing.)
>
>
> A line (without ends other than where it leaves the graph box) would not
> be a good idea.  It has to be a line segment, and probably an
> optionally curved one at that.  Which raises a serious problem about the
> command-line user interface we could provide to specify such a thing.
>
>
>> The contour plot algorithm apparently already knows how to create the
>> contours and whether they are lines or closed curves.  So, if it is
>> a closed curve, pick the starting point or some other rule.
>
>
> If it's closed, it doesn't really have a starting point, does it?


Not mathematically, but in the plotting routine it has to start 
somewhere.  But I'm sure the starting point for drawing the curve isn't 
necessarily the best position.

>
>> If it is an open curve, take the line that bisects the endpoints and 
>> find where that intersects the curve.
>
>
> No way.  The number of intersections can easily be zero, or could be
> a dozen.


I meant take the two end points and halfway between them strike a line 
perpendicular to the line connecting them.  That has to intersect the 
curve at at least one point.  Could be more.  Pick the first one.  What 
one would do is store the perpendicular line as a hyperplane.  Then as 
constructing the level curve one segment at a time, apply the position 
of the segment end points to the hyperplane.  If the sign changes there 
is an intersection.

Closed curves would be a different issue.  Maybe search for the extremal 
x/y points and draw a line through the corners...  I don't know, 
starting to ramble.

Of course, the optimum thing to do is to pick the location on the level 
curve that is furthest from it's neighboring level curves.  It has to 
work on general data, so gradient or such would be out.  Is there a way 
to compute such a thing while drawing contour segments?

Dan

Re: Contour plots

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

Daniel J Sebald wrote:

[...]
> I would too.  However, might it be possible to use some simple 
> algorithm that does an OK job in most cases?

I rather much doubt that such a thing exists.   In contouring, I suspect
most cases are too tricky for any simple algorithm.

> The worst case scenario is when the contours are rather small oval
> shapes, or rather close together.  But if it is unacceptable to the
> user, then he or she could turn off annotation.

We really need better control than just on/off on this.

> Rather than an optimization problem where we, say, pick a trajectory
> with the smallest gradient (i.e., largest spacing between contours),
> could we just pick some line for which to intersect as the spot to
> pick the label text?  (Intersecting with lines is a not so difficult
> thing.)

A line (without ends other than where it leaves the graph box) would not
be a good idea.  It has to be a line segment, and probably an
optionally curved one at that.  Which raises a serious problem about the
command-line user interface we could provide to specify such a thing.


> The contour plot algorithm apparently already knows how to create the
> contours and whether they are lines or closed curves.  So, if it is
> a closed curve, pick the starting point or some other rule.

If it's closed, it doesn't really have a starting point, does it?

> If it is an open curve, take the line that bisects the endpoints and 
> find where that intersects the curve.

No way.  The number of intersections can easily be zero, or could be
a dozen.

Some other random points:

*) I'm strictly against any GUI-only feature.  Once we have a suitable
command line method of specifying the locus of those contour labels, we 
can think of a mouse interaction method of doing the same.  We may even 
have to keep in mind that a GUI should be possible while setting up the 
command line syntax.  But command line is still *mandatory*.

*) We're going to paint labels in the middle of the data area.  I.e. we 
risk covering up critical aspects of the plotted data, which I consider 
a strict no-no.  That's why a simple on/off control would be 
insufficient.  We can't seriously expect users to accept that if the 
default placement puts on of  a dozen labels in some undesirable place, 
their only option is to give up on in-graph contour labels altogether 
(or roll their own by plotting an extra file 'with labels')

*) In-graph contour labelling must take into account whether a terminal 
can render rotated text or not.  There will be a considerably large 
number of cases where horizontal-only labels are hard or impossible to 
place, while text oriented parallel to the contour line would still work.

Re: Contour plots

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

Harald Harders wrote:

>On Thu, 27 Jan 2005, Daniel J Sebald wrote:
>
>  
>
>>Ethan Merritt wrote:
>>    
>>
>>>On Tuesday 25 January 2005 05:04 am, Hans-Bernhard Broeker wrote:
>>>      
>>>
>>>>Daniel J Sebald wrote:
>>>>        
>>>>
>>>>Right, it can't.  The main problem being that it's an absolute beast of
>>>>a problem to figure out *where* to put such labels
>>>>        
>>>>
>>>I agree that it is difficult.
>>>      
>>>
>>I would too.  However, might it be possible to use some simple algorithm
>>that does an OK job in most cases?  The worst case scenario is when the
>>contours are rather small oval shapes, or rather close together.  But if
>>it is unacceptable to the user, then he or she could turn off
>>annotation.  Rather than an optimization problem where we, say, pick a
>>trajectory with the smallest gradient (i.e., largest spacing between
>>contours), could we just pick some line for which to intersect as the
>>spot to pick the label text?  (Intersecting with lines is a not so
>>difficult thing.)
>>    
>>
>
>I think this is a good idea. Another could be that the user gives a curve
>in x-y space either by data points or by a parametric function. The labels
>for the contours could then positioned where the contours and the given
>line intersect.
>  
>

I was thinking that!  :-)  But I thought no one else would like that idea.

>>>On the other hand, the mousing code is now versatile enough
>>>that you could write a script to add the labels interactively.
>>>I can imagine a semi-automated mode in which you click twice,
>>>once at point X above and once and point Y above, and the script
>>>proceeds to add a label on each intervening contour.
>>>      
>>>
>>Ethan's mouse idea could work, but I think once one does that, people
>>will start asking for more and more mouse features to the point where
>>gnuplot becomes GUI oriented.  Which might be OK.
>>    
>>
>
>I dislike features that are only available by interaction of the user.
>What I does in most cases is to write a gnuplot file that is invoked by
>the command line. If you have to use the mouse after each small change it
>is really not good to me. Thus I think either an automatic or a
>script-driven possibility to put these labels has to exist. That does not
>mean that an additional mouse positioning was a bad idea.
>

I agree with that.  Mouse is good for zooming, no doubt there.  But it 
is always nice to build graphs from a file without any 
interaction--unless the labels could be stored somehow.  But still...

Dan

Re: Contour plots

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

On Thu, 27 Jan 2005, Daniel J Sebald wrote:

> Ethan Merritt wrote:
> >On Tuesday 25 January 2005 05:04 am, Hans-Bernhard Broeker wrote:
> >>Daniel J Sebald wrote:
> >
> >>Right, it can't.  The main problem being that it's an absolute beast of
> >>a problem to figure out *where* to put such labels
> >
> >I agree that it is difficult.
>
> I would too.  However, might it be possible to use some simple algorithm
> that does an OK job in most cases?  The worst case scenario is when the
> contours are rather small oval shapes, or rather close together.  But if
> it is unacceptable to the user, then he or she could turn off
> annotation.  Rather than an optimization problem where we, say, pick a
> trajectory with the smallest gradient (i.e., largest spacing between
> contours), could we just pick some line for which to intersect as the
> spot to pick the label text?  (Intersecting with lines is a not so
> difficult thing.)

I think this is a good idea. Another could be that the user gives a curve
in x-y space either by data points or by a parametric function. The labels
for the contours could then positioned where the contours and the given
line intersect.

> >On the other hand, the mousing code is now versatile enough
> >that you could write a script to add the labels interactively.
> >I can imagine a semi-automated mode in which you click twice,
> >once at point X above and once and point Y above, and the script
> >proceeds to add a label on each intervening contour.
>
> Ethan's mouse idea could work, but I think once one does that, people
> will start asking for more and more mouse features to the point where
> gnuplot becomes GUI oriented.  Which might be OK.

I dislike features that are only available by interaction of the user.
What I does in most cases is to write a gnuplot file that is invoked by
the command line. If you have to use the mouse after each small change it
is really not good to me. Thus I think either an automatic or a
script-driven possibility to put these labels has to exist. That does not
mean that an additional mouse positioning was a bad idea.

Harald

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

%%BoundingBox and %%Orientation in *.ps and *.eps files

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

Harald (and everyone else):

You mention in your patch comments

>Date: 2005-01-26 16:44
>Sender: harders
>
>- Remove the '%%Orientation: ...' line from all kinds of eps
>  graphics since it confuses ghostscript 8.5. In normal
>  postscript (landscape, portrait) this statement remains existing.

It is true that %%Orientation should not appear in an *eps file.

But in looking this up in the PostScript Reference Manual I also
notice that there is a distinction between

%%BoundingBox and %%PageBoundingBox

An *eps file should use only %%BoundingBox.  So we're OK there.

But the existence of %%PageBoundingBox seems directly relevant
to recent discussion on the use of "set size" before and
after "set term".  

I believe that the sequence
  set size <x>,<y>
  set term post
should alter the contents of %%BoundingBox

But the sequence
  set term post
  set size <x>,<y>
  plot "foo"
  set size <x2>,<y2>
  plot "baz"
should in principle be setting %%PageBoundingBox each time
the size is changed. At the end of the file, %%BoundingBox
is set to the maximum values ever used for individual pages.

Is it worth making this change?


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

Re: Contour plots

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

Ethan Merritt wrote:

>On Tuesday 25 January 2005 05:04 am, Hans-Bernhard Broeker wrote:
>  
>
>>Daniel J Sebald wrote:
>>
>>    
>>
>>>Also, I just want to confirm that gnuplot contours can't do the 
>>>following type of labelling?
>>>      
>>>
>        X
>  
>
>>>------ 20 ------
>>>
>>>------------ 30 --------
>>>      
>>>
>                     Y
>  
>
>>Right, it can't.  The main problem being that it's an absolute beast of
>>a problem to figure out *where* to put such labels
>>    
>>
>
>I agree that it is difficult.
>  
>

I would too.  However, might it be possible to use some simple algorithm 
that does an OK job in most cases?  The worst case scenario is when the 
contours are rather small oval shapes, or rather close together.  But if 
it is unacceptable to the user, then he or she could turn off 
annotation.  Rather than an optimization problem where we, say, pick a 
trajectory with the smallest gradient (i.e., largest spacing between 
contours), could we just pick some line for which to intersect as the 
spot to pick the label text?  (Intersecting with lines is a not so 
difficult thing.)

The contour plot algorithm apparently already knows how to create the 
contours and whether they are lines or closed curves.  So, if it is a 
closed curve, pick the starting point or some other rule.  If it is an 
open curve, take the line that bisects the endpoints and find where that 
intersects the curve.  I can already imagine what you meant, Hans, (the 
tangled web I weave) but when the strange level curves happen, the 
annotation could be disabled by the user.

>On the other hand, the mousing code is now versatile enough
>that you could write a script to add the labels interactively.
>I can imagine a semi-automated mode in which you click twice,
>once at point X above and once and point Y above, and the script
>proceeds to add a label on each intervening contour.
>
>The demo below was written for a different purpose, but it
>illustrates some of the same ideas:
>  
>

OK, so Ethan has already given a Bessel function example where the 
contours get a bit wacky.  But because of the crowded closed curves in 
the x=1.5 to 2.5 band, this would probably be one where the user asks to 
not annotate the contours.  Otherwise the plot would be riddled with text.

Ethan's mouse idea could work, but I think once one does that, people 
will start asking for more and more mouse features to the point where 
gnuplot becomes GUI oriented.  Which might be OK.

So the routine would do some type of interpolation and figure out what 
the value of the level curve nearby should be?  (Not saying you should 
do this, but just wondering what you have in mind.)  Perhaps not the 
easiest thing either, Ethan, once those level curves get close 
together.  You are relying on the user to properly point to the curve of 
interest of which there may be a few nearby.

Dan

Re: Comment for pgnuplot

[Tatsuro M. <mat...@nu...>]

>No.  The secondary cast to (unsigned int) is unnecessary, and 
>potentially dangerous (because the real parameter type is WPARAM, not 
>unsigned int).  I've checked into a CVS a version that casts to unsigned 
>char.
>If the type were unsigned int, such a cast would be superfluous --- C 
>silently applies it already.

Thank you for your comments.

  PostMessage( hwnd, WM_CHAR, (unsigned char) *pc, 1L );

Is it OK?  It look like works well here.

>> Sometimes I used the script which includes more than 80 character per line.
>So what?  Did the existing buffer size of 80 cause you any trouble with 

This is my complete misleading.  I'm sorry.

Sincerely yours,
Tatsuro MATSUOKA

Now working on POV-Ray terminal

[KITA T. <t-...@cc...>]

I am astonished to see the thread starting with
From: Varoquaux <varoquau@cl...>
Povray terminal output  
2005-01-16 06:02 .

# I am sorry I can not append my mail to the thread.  I just submitted.

> This is a bit a crazy idea, but I was wondering if it would be possible to
> have a povray terminal output for gnuplot, a bit like the latex terminal. 

I and one of my students, Miyata, are currently working on the
POV-Ray and VRML terminal of gnuplot.

For several months we have explored and modified the source files under src/,
and it is beginning to work now.

It is just a alpha-version and not so neatly written.
Maybe in several weeks we can provide our patch file to add these two
terminals here at this ML.

Followings are the sample images created by povray (originally TGA
 formatted) with our output files :
(only 'plotting with points' is possible now)

http://alt.cc.kumamoto-u.ac.jp/tmp/tt1.jpg
http://alt.cc.kumamoto-u.ac.jp/tmp/tt2.jpg
http://alt.cc.kumamoto-u.ac.jp/tmp/tt3.jpg

Output files are like this :

http://alt.cc.kumamoto-u.ac.jp/tmp/tt1.pov

-- 
  KITA Toshihiro
  http://t-kita.net/    PGP-Key: http://t-kita.net/pubkey.asc
  fingerprint : CBFF 6A61 5990 10F5 B4B6  D2E8 279A 7063 CF8B 6339

Re: Comment for pgnuplot

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

Tatsuro MATSUOKA wrote:
> Does your suggestion mean that change for the function PostString should be like below?

> ************************************************************
> void PostString(HWND hwnd, char *pc)
> {
> 	while( *pc ){
> 		PostMessage( hwnd, WM_CHAR,(unsigned int) ((unsigned char) *pc), 1L );
> 		/* CRS: should add a check of return code on PostMessage. If 0, the 
> 		   message que was full and the message wasn't posted. */
> 		pc++;
> 	}
> }
> **************************************************************

No.  The secondary cast to (unsigned int) is unnecessary, and 
potentially dangerous (because the real parameter type is WPARAM, not 
unsigned int).  I've checked into a CVS a version that casts to unsigned 
char.

> According to the windows SDK page, the type of third parameter of PostMessage is UINT
> so that casting (unsigned int)  is added.

If the type were unsigned int, such a cast would be superfluous --- C 
silently applies it already.

>>>The buffer size is rather small. (80) I think it should be larger
>>>(eg.512).
>>>
>>>"#define BUFFER_SIZE 512"
>>
>>What do you think would be gained by that?  Please note that the size of
>>this buffer may very well be a critical parameter that determines how
>>well pgnuplot works in a somewhat busy Windows environment.
> 
> Sometimes I used the script which includes more than 80 character per line.

So what?  Did the existing buffer size of 80 cause you any trouble with 
those lines?

Re: Comment for pgnuplot

[Tatsuro M. <mat...@nu...>]

Thnak you for your reply,

>While that may appear to work well, I doubt it's the right way of going
>at it.  The data passed to this function are actually type char *, not
>unsigned char *, and casting a pointer from one type to another is
>always a dangerous thing to do, even more so if it's supposed to happen
>this silently, by argument conversion.  The correct method would rather
>appear to be a cast of the character being sent to 'unsigned char', as
>it's passed to the Windows API function PostMessage.

Does your suggestion mean that change for the function PostString should be like below?

************************************************************
void PostString(HWND hwnd, char *pc)
{
	while( *pc ){
		PostMessage( hwnd, WM_CHAR,(unsigned int) ((unsigned char) *pc), 1L );
		/* CRS: should add a check of return code on PostMessage. If 0, the 
		   message que was full and the message wasn't posted. */
		pc++;
	}
}
**************************************************************

According to the windows SDK page, the type of third parameter of PostMessage is UINT
so that casting (unsigned int)  is added.

In the Gnuplot Thead in Japan, it was pointed out that
this modification might be effective for people using the iso-8859-* encoding .

Unfortunately we cannot try this, because we do not have a such computer environment.


>
>> The buffer size is rather small. (80) I think it should be larger
>> (eg.512).
>> 
>> "#define BUFFER_SIZE 512"
>
>What do you think would be gained by that?  Please note that the size of
>this buffer may very well be a critical parameter that determines how
>well pgnuplot works in a somewhat busy Windows environment.
Sometimes I used the script which includes more than 80 character per line.
If this BUFFER_SIZE is critical, I will notice this from now 
when I use pgnuplot.  Thanks!!

Sincerely yours

Tatsuro MATSUOKA.

Re: Povray terminal output

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

On Tue, 25 Jan 2005, Petr Mikulik wrote:

> >   I am a bit in a hurry, right now, so here is an splot with pm3D, the
> > povray version and the gnuplot version.
> >
> > www.eleves.ens.fr/home/varoquau/2Dlattice.png
> > www.eleves.ens.fr/home/varoquau/2Dlattice.pov
> > www.eleves.ens.fr/home/varoquau/gnuplot-2Dlattice.png
>
> The surface in povray is OK, but what about axes and their labels, and also
> the colorbox?

I have had posted a few links that show possible ways to handle axes. If
they are useful is another question. Here once again the links:

http://www.harald-harders.de/gnuplot/hindernisabstand1.png (280KB)
http://www.harald-harders.de/gnuplot/hindernisabstand1a.jpg (68KB)
http://www.harald-harders.de/gnuplot/funktion3.png (136KB)
http://www.harald-harders.de/gnuplot/funktion3.pov (3716KB)
http://www.harald-harders.de/gnuplot/funktion3.ini (4KB)

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

postscript/epslatex terminal and pattern fill

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

In comp.graphics.apps.gnuplot #32829
=46rom "news.uibk.ac.at" <Gre...@ui...> wrote

>I have some questions to the active developers of gnuplot, especially Etha=
n A.
>Merrit regarding the pattern fill definitions in the postscript and epslat=
ec
>terminal. (I am just trying to improve the epslatex terminal and stumbled =
on
>this point. And yes I know, there is a patch pending...)

>My impressions of the current status are (perhaps they are wrong): the
>epslatex terminal seems to use Poscript Level 1 pattern fill.=20

There are two separate driver routines that produce filled areas.
term->fillbox() does rectangles only
term->filled_polygon() does general polygons.

The latter routine is obviously more general, but as currently implemented
it requires PM3D support so not all terminals can provide it.  I have been
slowly working to disentangle polygons from PM3D so that even non-PM3D
terminals can draw filled polygons.

As to epslatex:

The EPSL_filled_polygon() routine is just a pointer to the one in the
postscript driver.

The EPSL_fillbox() is a private routine to the epslatex driver. It
outputs calls to the same pattern-fill macros used by the postscript
driver until very recently.  We cleaned up the postscript driver's own
Level1/Level2 support several months ago. Perhaps the same cleanup
should be applied to epslatex.
  =20

>In the=20
>postscript terminal there are several possibilities present in the source
>code: Postscript Level 1 patterns, Level 2 patterns and a postscript macro
>that appropriately draws lines, but only can fill rectangular boxes.

Correct.

>Only the latter is used at the moment.

I'm not sure what you mean by that.  The current (CVS) postscript driver
uses either Level1 or Level2 pattern fill depending on what the printer
supports. You can override this by a command line option or by editing the
output file.  The current (CVS) epslatex driver uses Level2 pattern fill.

>From a technical point of view using Postscript pattern fill seems prefera=
ble
>since arbitrary shapes can be filled. However, the line draw method gives
>nicer results when viewed on screen (with ghostscript or Acrobat reader af=
ter
>conversion to pdf).

Both ghostview/gv and Acrobat are buggy in their own idiosynchratic ways.
There's not much we can do about that.
You could try xpdf or kpdf, which no doubt have their own set of problems.

>Now my questions:
>What are the rationales for the decisions that led to the current implemen=
tations?

Historical development.  The generic pattern-fill macros were developed
so that we could fill areas other than rectangular boxes.

>What are the drawbacks when using the line draw method compared to the
>Postscript pattern fill method?

Only works for rectangles.

>Are there plans to support enhanced pattern fill possibilities (colored
>patterns, arbitrary shapes, more and user defined?

Colored patterns and arbitrary polygon fill are already supported.

As to user customization, there is in a sense a plan that would
allow this.  Back when we were packaging up version 4.0 for release
we experimented briefly with pulling the PostScript Prolog, encoding
option code, and other initializations out of the driver source and
having them loaded at run time.  The motivation at the time was to
reduce the code size of the postscript driver.  But it has the nice
(IMHO) side effect that a user can modify the Prolog, including
macro definitions like pattern fill, without having to edit and
rebuild gnuplot itself.  This would also allow site-specific
customization of page size, default character encoding, etc, for
PostScript output.

The only strong objection I recall was that keeping track of external
files required at run time may be problematic under Windows.
I am not familiar with Windows at either the development or user
level, so I'm of no help in sorting this out if it is in fact a
problem. From my side it would be easy enough to have the driver
look first in ~/.gnuplot/Prolog.ps and second in=20
/usr/local/share/gnuplot/Prolog.pa


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