Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2005-01-23 10:07:47
|
I don't know if anyone put any thought into the proper behavior of changing the terminal while some output file is still open, but current behavior seems undefined or of no use. Maybe closing the output after a terminal command is the thing to do, but I don't thing gnuplot behaves that way. This has come to my attention because in Octave I'd wondered if there was a way to leave a PostScript file or PDF file open, switch over to X11 to do some plots, switch back to the PS or PDF terminal and place another plot in the file. (Octave does stem plots as two successive plots.) In other words, in Octave this would be similar to the "print -dpdf" command but not closing the file in between plots. Anyway, back on to behavior. Try set term post color solid set output 'junk.ps' plot sin(x) set term x11 plot cos(x) set term post color solid replot set output OK, what's strange about this is that gnuplot still prints PostScript code to the file 'junk.ps' after switching to and back from "set term x11". The content of the file from the first "plot sin(x)" is erased, then the result of "replot" is sent to the file. But then there is the additional non-consistency of the PostScript file not being in color as indicated by the set term. As I said before, this is probably undefined. But I'd think a more "defined" or logical behavior would 1) The "set term" causes the output file to be closed as though a "set output" had been issued just before "set term"; or 2) The file is not actually closed and it is possible to continue to write to the file using a different terminal. If the user mixes incompatible file types, that's his or her problem to clear up. Alternative 2 would allow plotting in the x11 terminal in an intermediate fashion. Dan |
|
From: Daniel J S. <dan...@ie...> - 2005-01-25 05:40:57
|
Daniel J Sebald wrote: > This has come to my attention because in Octave I'd wondered if there > was a way to leave a PostScript file or PDF file open, switch over to > X11 to do some plots, switch back to the PS or PDF terminal and place > another plot in the file. (Octave does stem plots as two successive > plots.) For those interested, the plot scripts of Octave have just been updated to plot all data at once as opposed to a series of "replots": http://www.octave.org/cgi-bin/viewcvs.cgi/octave/scripts/plot/ This makes for nicer behavior in all plot terminals... and obviates the need for any alternate behavior of switching terminals when the output file is left open. ... Also, I just want to confirm that gnuplot contours can't do the following type of labelling? ------ 20 ------ ------------ 30 -------- If they can, let me know. Otherwise, maybe a project for summer. Dan |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-01-25 13:02:48
|
Daniel J Sebald wrote: > Also, I just want to confirm that gnuplot contours can't do the > following type of labelling? > > ------ 20 ------ > > ------------ 30 -------- 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, and not make a complete fool out oneself half the time. Re-writing TeX's layout algorithm from scratch might be a piece-of-cake, in comparison. |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-25 17:06:47
|
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.
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:
# Contour-slice demo
# Ethan A Merritt <merritt@u.washington.edu>
#
set samples 40, 40
set isosamples 41, 41
set contour base
set cntrparam levels auto 10
set title "Interactive contour slicing demo"
f(x,y) = sin(x) * cos(y)
f(x,y) = sin(13*besj0(x)) * cos(y/ (0.1 + (abs(x-2.))) )
# Plot function with contours
set view map
unset surface
splot [x=-0:4] [y=0:2] f(x,y)
pause mouse "Click on some point\n"
x0 = MOUSE_X
y0 = MOUSE_Y
pause mouse "Click on another point\n"
x1 = MOUSE_X
y1 = MOUSE_Y
# Show selected path
set arrow 1 from x0,y0 to x1,y1
replot
pause -1 "Hit return to plot contours along this slice"
unset arrow 1
# Define parametric function running along this line
g(z) = f( x0 + z*(x1-x0), y0 + z*(y1-y0) )
# Plot the value of f(x) along the selected path
set xlabel "Fractional distance along selected path"
set samples 500
unset key
set label 1 sprintf("(%.3f,%.3f)",x0,y0) at 0,g(0) tc lt 3
set label 2 sprintf("(%.3f,%.3f)",x1,y1) at 1,g(1) right tc lt 3
plot [x=0:1] g(x)
pause -1
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Daniel J S. <dan...@ie...> - 2005-01-27 21:19:29
|
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 |
|
From: Harald H. <h.h...@tu...> - 2005-01-27 21:53:26
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2005-01-27 22:04:41
|
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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-01-28 08:39:34
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2005-01-28 09:15:02
|
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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-01-28 12:16:12
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2005-01-28 18:49:50
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-01-28 21:39:46
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2005-01-29 01:34:43
|
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 |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-01-30 18:54:47
|
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. |
|
From: Harald H. <h.h...@tu...> - 2005-01-28 21:53:33
|
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
|
|
From: Hans-Bernhard B. <br...@ph...> - 2005-01-30 19:08:05
|
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. |
|
From: Daniel J S. <dan...@ie...> - 2005-01-30 19:35:06
|
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 |
