gnuplot development

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.harders@...
http://www.harald-harders.de

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@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

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.harders@...
http://www.harald-harders.de

Ethan Merritt wrote:
[...]
> 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.

Not everytime the 'set size' changes, though.  Just everytime a new page 
is started with a different 'set size' in effect.  The difference 
becomes important if 'multiplot' is in use, where 'set size' doesn't 
actually control the page size if used between 'set multiplot' and 
'unset multiplot'.

On Sunday 30 January 2005 11:59 am, Hans-Bernhard Broeker wrote:
>
> Not everytime the 'set size' changes, though.  Just everytime a new page
> is started with a different 'set size' in effect.  The difference
> becomes important if 'multiplot' is in use, where 'set size' doesn't
> actually control the page size if used between 'set multiplot' and
> 'unset multiplot'.

Of course you are correct.

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

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.harders@...
http://www.harald-harders.de

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

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.

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

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.

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

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@...
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

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.harders@...
http://www.harald-harders.de

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

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.

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.

Hans-Bernhard Broeker wrote:

> 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;


I agree with that.  "cntrparam" is too obscure.  "cntr" could mean 
"counter", or "control" or whatever the user's preconceived notion of 
"cntr" is.  Also, my first thought was "set cntrparam", realizing it was 
part of contour, was in fact the label of level curves.

Dan

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.harders@...
http://www.harald-harders.de

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/

>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