Menu
▾
▴
gnuplot-beta
|
From: Ethan M. <merritt@u.washington.edu> - 2005-09-16 20:56:43
|
Try the following: set key box title "Foo" splot 1,2,3,4,5 Everything is OK so far. Now try: set key rmargin replot That's not what I expected, but let's proceed. set key tmargin replot Huh? The box is no longer correct. set key lmargin replot Seems to be a no-op. Key is still broken. set key title "A much longer title" replot And now it's obvious that the title centering is not correct, either. Now let's start again (2D this time) reset set key box title "A much longer title" plot 1,2,3,4,5 In 2D the title is centered, but the box is not adjusted to fit it. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2006-02-06 01:12:48
Attachments:
key_title_2d_bug-5feb2006.patch
|
Alright, I've had a look at this issue. I'm not so sure these are bugs in the new key placement code. Rather, they are "bugs" in the old code, especially the 3d plots... Ethan Merritt wrote: > Try the following: > > set key box title "Foo" > splot 1,2,3,4,5 > > Everything is OK so far. Now try: > > set key rmargin > replot > > That's not what I expected, but let's proceed. > > set key tmargin > replot > > Huh? The box is no longer correct. > > set key lmargin > replot > > Seems to be a no-op. Key is still broken. > > set key title "A much longer title" > replot > > And now it's obvious that the title centering is not > correct, either. > The reason none of this makes sense is an issue that goes way back. I recall Hans saying something about "we have to fix that" in an exasperating tone regarding the fact that 3d plots never really have had a margin. (Take a close look at the layout when typing the above commands... the plot itself never moves.) The color box was always plopped down on the right edge, but no room was ever left for it, so the plot looked unbalanced. And now it is the same sort of thing with margin key placement in 3d. I realize it could be made a tad better than it is, but I probably figured at the time to not even touch 3d layout until the issue of margins was worked out. Let it be because anything I would have done would probably have not agreed with someone. That, and the fact that I think it would have been wasted coding effort on my part in the long run. The issue, I suppose, is that 3d plots have interactive rotation and zoom. That operation might conflict with any key, color box, etc. Why wasted coding effort? Because my personal feeling is that 2d/3d should be laid out the same in terms of margins, so that code should be unified. From what I recall, I cleaned up 2d layout nicely, so my suggestion would be to somehow move that to a file or organize it in a way that can be reused by both 2d and 3d. There's no way I could have pulled that off without complaints. I guess I'm pleading no quick fix here. Who want's to maintain two different sets of key code? But it will require someone with a big block of time. (More a little further down.) So, I think the group has to decide: revamp? Or band-aid the 3d code? > Now let's start again (2D this time) > > reset > set key box title "A much longer title" > plot 1,2,3,4,5 > > In 2D the title is centered, but the box is not adjusted > to fit it. OK, so I think this is the only "bug". (2d key behavior is all that concerns me right now.) I can't recall changing anything in the interior of the key, so all the things about Left/Right space etc. I'm not sure I've influenced. Maybe I overlooked something and changed interior behavior, but not sure. Anyway, attached is a line change that will put a little more space outside the title. Is that what you were concerned about Ethan? But notice that this still doesn't fix matters. Try these lines: set key box title "A much longer title" plot 1,2,3,4,5 set key Left replot Still no space at left of sample text. One could go tweaking that, but it's liable to break something. Recall we have instances of multicolumn keys now. What makes the code difficult to read is all the constants "+ 2" here, "- 1.5" there. These should all be defines or a variable. Perhaps there should be a variable that controls the amount of space surrounding things. I don't know. My suggestion would be: 1) Make a committment to combining plot layout for 2d and 3d into the same reusable code. Otherwise, it's a double migraine. 2) Restructure the C files and code using the 2d margins and key as the initial start. Then start looking to make interiors of keys better and more versatile. 3) There is now multicolumn keys, sort of. Perhaps formalize that and also maybe formalize multiple key concept. Draw up an Xfig diagram that can be converted to EPS or combine tex/PS showing all the elements of key and key layout; the little spaces here, the number of columns there, alignment, etc. (I.e., do the documentation first... basically a diagram similar to the page layout parameters of Figure C.3 of appendix C.5.3 in Lamport's LaTeX book.) Submit that to the list for agreement. 4) Code away to meet those definitions, which basically would mean replacing all the "+ 2", "0.5 *", etc. with definitions as shown in the documentation from 3. 5) Maybe add a Center to Left/Right/Center. In the "A much longer title" example Ethan gave, neither the Left nor the Right looks particularly great. Without a solid concept of keys and layout, it's just shuffling cards around in the house. It would have to be a summer project, but I'm not offering or committing to do any of this right now in light of the conversation of the last month regarding the future of gnuplot. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-02-07 06:05:43
|
On Sunday 05 February 2006 05:21 pm, you wrote: > Alright, I've had a look at this issue. > I'm not so sure these are bugs in the new key placement code. > Rather, they are "bugs" in the old code, especially the 3d plots... Huh? I think you are not focusing on the same issue that I am. Or possibly you are not even seeing the problem. I'm not talking about the margin spacing at all. Yeah, it's imperfect, but I don't care so much about that. What I'm pointing out as a bug is ... > > set key box title "Foo" > > splot 1,2,3,4,5 > > > > Everything is OK so far. Now try: > > > > set key rmargin > > replot > > > > That's not what I expected, but let's proceed. > > > > set key tmargin > > replot > > > > Huh? The box is no longer correct. By which I mean that the key box got smaller. It was originally the correct size to contain the set of titles. But for some reason this command causes it to shrink vertically, so the final title now appears below the key box. That's got to be a bug, pure and simple. Once we figure out how big the box needs to be, it should be drawn at that size no matter where on the graph window it sits. > And now it is the same sort of thing with margin key placement in 3d. I'm not worrying overly much about the placement. It's the fact that the *size* is not calculated consistently. Most of the time it is correct, but some key placement options seem to break the size calculation. > Because my personal feeling is that 2d/3d should be laid out the same in > terms of margins, so that code should be unified. I disagree, but not strongly. Anyhow, that's not what I'm complaining about. Since the time I originally sent this message, the centering code seems to have been fixed. Intentionally or unintentionally - I don't know. But the incorrect centering I pointed to originally is no longer there in current cvs. > I'm not offering or committing to do any of this right now in light of > the conversation of the last month regarding the future of gnuplot. Oh? I didn't think much new came out of that discussion. We're still in exactly the state we always were. Except that we are now, I hope, much closer to a 4.2 release :-) [gotta go back to emptying out that bug list] -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Daniel J S. <dan...@ie...> - 2006-02-07 06:52:43
|
Ethan A Merritt wrote: > > By which I mean that the key box got smaller. > It was originally the correct size to contain the > set of titles. But for some reason this command > causes it to shrink vertically, so the final title > now appears below the key box. That's got to be > a bug, pure and simple. Once we figure out how big > the box needs to be, it should be drawn at that size > no matter where on the graph window it sits. Yes, I saw that. I could make a guess why the box is too small... I don't know, maybe because the way things are laid out the key code thinks there isn't much room so chooses a small box to fit within its allotted space. >>And now it is the same sort of thing with margin key placement in 3d. > > > I'm not worrying overly much about the placement. > It's the fact that the *size* is not calculated consistently. > Most of the time it is correct, but some key placement options > seem to break the size calculation. In 3d. I've tried this for "plot" and the box is correct. The point is, there are two sets of key code. That for 3d needs some fixes. >>Because my personal feeling is that 2d/3d should be laid out the same in >>terms of margins, so that code should be unified. > > > I disagree, but not strongly. Why? > Anyhow, that's not what I'm complaining about. I know. But I'm inquiring with people if from a coding standpoint they feel there should be two different sets of layout or just one. (I think Hans pointed out a long time ago that graph3d.c came from graphics.c by tagging a "3d" to most of the functions within.) If someone can argue the layout should be kept separate, fine. But I can't see a good reason to do so, and the points of consistency (for the user's sake) and ease of maintaining code (for the programmer's sake) are what I'm emphasizing. The question is: Put effort into touching up the 3d keys, or put effort into unifying plot layout, effectively fixing 3d keys? I'm guessing Ethan would rather see those 3d keys fixed than attempt to unify 3d/2d key code. > > Since the time I originally sent this message, the centering code > seems to have been fixed. Intentionally or unintentionally - I don't know. > But the incorrect centering I pointed to originally is no longer there > in current cvs. OK. Dan |
|
From: Ethan A M. <merritt@u.washington.edu> - 2006-02-07 07:07:07
|
On Monday 06 February 2006 11:00 pm, Daniel J Sebald wrote: > > The question is: Put effort into touching up the 3d keys, > or put effort into unifying plot layout, effectively fixing 3d keys? I don't see how you *could* unify the 2D key and the 3D key. They are intrinsically different. The 2D case has a fixed plot border (not the canvas border, the plot border) within which we normally position the key. 3D plots *have* no such border except in the special case of `set view map`. So even if you unified many of the 2D and 3D routines, I think you would still need two parallel bits of code for key placement. -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From:
<br...@ph...> - 2006-02-07 18:07:30
|
Ethan A Merritt wrote:
> I don't see how you *could* unify the 2D key and the 3D key.
That should actually be quite simple. The reason it's not is that the
3D code and the 2D code are currently a *lot* more different than they
really have to be.
> They are intrinsically different. The 2D case has a fixed
> plot border (not the canvas border, the plot border) within
> which we normally position the key. 3D plots *have* no
> such border except in the special case of `set view map`.
The 3D plots do have such a border. Its real shape is not a rectangle,
though. It's an ellipse, inside which the plot can take different
orientations according to 'set view'.
The 2D layout of 3D plots currently works like this:
* 'set size' & 'set origin' define a rectangular area on the page.
This is what the 4.0 'help glossary' calls "a plot".
* Inside this rectangular area, there's a "canvas", stored in struct
plot_boundary. It's margins relative to the plot area are controlled by:
+ left: 'set lmargin' or a default (2 chars + 1 tic),
+ right: (2 chars + 1 tic) + ('set key outside'? key box width)
+ bottom: 2.5 chars + 1 pixel(?) + ('set key below'? key box height)
+ top: 'set title' + 1.5 chars + 1 pixel(?)
* the center of this canvas becomes the center of the 3D output
(xmiddle, ymiddle). The design size of the 3D graph box is 1/sqrt(3)
(approximated as 4/7) of the canvas (--> xscaler, yscaler), but the
actual area occupied by the data is a circle enscribed into the
plot_boundary rectangle. This is the rectangle filled with data in
'set view 0,0,1,1' splots. In other orientations, some parts of
the box will be outside this region, but they'll always stay
inside the plot_boundary region above.
* 'set view' controls the mapping from normalized 3D graph coordinates
onto this 2D region.
Yes, there are a lot of things going on there that range from the very
strange to the outright buggy. The fact that the relevant function,
boundary3d(), is so much shorter than its 2D cousin boundary(), even
though its job really is a good deal more complicated, serves as a
warning that much ground is left to be covered here: no space is
reserved for tics, ticlabels, axis labels, the time stamp; the t, b and
r margins are ignored, as well as 'set offsets'.
There are two obvious choices for the rectangle with respect to which
the key positioning should work:
* struct plot_boundary
* the 4/7 downscaled one that contains the graph in 'set view 0,0'
position.
The current code uses struct plot_boundary, which leaves the key outside
the actual plot area simply because the elliptical area used by actual
data doesn't reach all the way into the corners of the rectangle.
|
|
From: Daniel J S. <dan...@ie...> - 2006-02-08 03:05:41
|
Hans-Bernhard Br=F6ker wrote: > Ethan A Merritt wrote: >=20 >> I don't see how you *could* unify the 2D key and the 3D key. >=20 >=20 > That should actually be quite simple. The reason it's not is that the=20 > 3D code and the 2D code are currently a *lot* more different than they=20 > really have to be. >=20 >> They are intrinsically different. The 2D case has a fixed >> plot border (not the canvas border, the plot border) within >> which we normally position the key. 3D plots *have* no >> such border except in the special case of `set view map`. >=20 >=20 > The 3D plots do have such a border. Its real shape is not a rectangle,= =20 > though. It's an ellipse, inside which the plot can take different > orientations according to 'set view'. Sort of; until zooming as it currently exists is factored into the pictur= e. Then the border is rectangular and lines near the border behave stran= gely. > Yes, there are a lot of things going on there that range from the very=20 > strange to the outright buggy. The fact that the relevant function,=20 > boundary3d(), is so much shorter than its 2D cousin boundary(), even=20 > though its job really is a good deal more complicated, serves as a=20 > warning that much ground is left to be covered here: Exactly. Couldn't have said it better. no space is=20 > reserved for tics, ticlabels, axis labels, the time stamp; the t, b and= =20 > r margins are ignored, as well as 'set offsets'. >=20 > There are two obvious choices for the rectangle with respect to which=20 > the key positioning should work: >=20 > * struct plot_boundary >=20 > * the 4/7 downscaled one that contains the graph in 'set view 0,0' > position. >=20 > The current code uses struct plot_boundary, which leaves the key outsid= e > the actual plot area simply because the elliptical area used by actual=20 > data doesn't reach all the way into the corners of the rectangle. Yes, but just barely. The balance doesn't look good. Dan |
|
From: Petr M. <mi...@ph...> - 2006-02-08 17:28:42
|
> The 3D plots do have such a border. Its real shape is not a rectangle, > though. It's an ellipse, inside which the plot can take different > orientations according to 'set view'. > > actual area occupied by the data is a circle enscribed into the > plot_boundary rectangle. This is the rectangle filled with data in > 'set view 0,0,1,1' splots. In other orientations, some parts of Thus, there exists a bounding rectangle of that ellipse/circle. This could be manipulated by all of the set margin's, not only the lmargin. Isn't this functionality feasible to add? --- PM |
|
From:
<br...@ph...> - 2006-02-08 19:24:37
|
Petr Mikulik wrote: > Thus, there exists a bounding rectangle of that ellipse/circle. This > could be manipulated by all of the set margin's, not only the lmargin. > Isn't this functionality feasible to add? Sure. boundary3d() can use a lot of improvement. Only question is: do this incrementally, risking an end state that is a rather tangled mess, or allow someone the time to really work on this, and get it _right_? Things that really need doing in this area: 1) add more 'coordinate' classes for 3D plots, if only for debugging. We need commands like set arrow from view 0,0,0 to view 1,1,1 # 'camera' coordinates set arrow from canvas 0,0 to canvas 1,1 # the 'plot_boundary' to analyze what actually goes on in 3D layout. The main problem with the current layout is that even among us, the developers, nobody really knows what goes where, and why, in 3D, because none of the relevant boundaries can easily be displayed on the plot. 2) Extend boundary3d(): add handling for the other 3 margins, 'set offsets', and completely re-think space reservations for ticks, ticklabels, and axis labels. 3) Completely re-do the implementation of 'set view map', getting rid of temporary overrides of 'set' values for ranges, reverse states etc. The number of places the value of splot_map is checked is well beyond the acceptable. We've been piling band-aids upon kludges upon hacks to implement this feature. That has to stop. 4) get rid of the internal surface_scale variable and all it entails. Obsolete <scale> parameter in 'set view', achieve its effect in other ways. 5) same as 4), for surface_scale_z --- that one's just plain wrong. 6) While at it, add point-perspective projection. |
|
From: Petr M. <mi...@ph...> - 2006-02-08 23:13:57
|
> Sure. boundary3d() can use a lot of improvement. Only question is: do this > incrementally, risking an end state that is a rather tangled mess, or allow > someone the time to really work on this, and get it _right_? Fixing the most obvious "bugs" (=missing functionality) now. > 1) add more 'coordinate' classes for 3D plots, if only for debugging. We need > commands like > > set arrow from view 0,0,0 to view 1,1,1 # 'camera' coordinates > set arrow from canvas 0,0 to canvas 1,1 # the 'plot_boundary' Aha, there is no coordinate system for the bounding rectangle of the 3D? Do we need it? This looks like a bug: set arrow 1 from graph 0,0,0 to graph 1,1,1 splot x*y pause -1 set view map replot pause -1 plot x I would expect a line in another diagonal. > 2) Extend boundary3d(): add handling for the other 3 margins, 'set offsets', > and completely re-think space reservations for ticks, ticklabels, and axis > labels. You mean 'set margins'? I think this is the most easy and helpful fix. This would allow to scale down the 3D plot area manually in order to allow enough space for the color box when needed. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-02-09 08:34:18
|
Petr Mikulik wrote: >> Sure. boundary3d() can use a lot of improvement. Only question is: >> do this incrementally, risking an end state that is a rather tangled >> mess, or allow someone the time to really work on this, and get it >> _right_? > > > Fixing the most obvious "bugs" (=missing functionality) now. Easier and more obvious, but still would require significant file restructure. > >> 1) add more 'coordinate' classes for 3D plots, if only for debugging. >> We need commands like >> >> set arrow from view 0,0,0 to view 1,1,1 # 'camera' coordinates >> set arrow from canvas 0,0 to canvas 1,1 # the 'plot_boundary' > > > Aha, there is no coordinate system for the bounding rectangle of the 3D? > Do we need it? > > This looks like a bug: > set arrow 1 from graph 0,0,0 to graph 1,1,1 > splot x*y > pause -1 > set view map > replot > pause -1 > plot x > > I would expect a line in another diagonal. Looks like a bug. In 3d space the arrow goes from -10,-10 to 10,10. So, unless map is something quite different from 3d, the project seems wrong. > >> 2) Extend boundary3d(): add handling for the other 3 margins, 'set >> offsets', and completely re-think space reservations for ticks, >> ticklabels, and axis labels. > > > You mean 'set margins'? I think this is the most easy and helpful fix. > This would allow to scale down the 3D plot area manually in order to > allow enough space for the color box when needed. I think he means the spacing along the axes margins, which as Ethan pointed out, are very different than the canvas margins. The example you gave above, if one looks at the tick mark text in some cases it overlaps with the axes line and doesn't look good. Sure, in some cases this is difficult to avoid because of the viewing angle. But the default view angle should at least look pretty good. [I seem to recall the color box was at one time drawn in the plot coordinates and used to rotat around with the graph. Remember that?] Then replot the 3d example after set xlabel 'xlabel' set ylabel 'ylabel' set zlabel 'zlabel' Again, for some viewing angles the text is way out further than it need be. [And if you could draw the axis labels using rotated text, you might have a real winner.] I think this is the more difficult task that Hans refers to: making that axes annotation look good in all views. Dan |
|
From: Petr M. <mi...@ph...> - 2006-02-09 16:37:11
|
> because of the viewing angle. But the default view angle should at least > look pretty good. > > [I seem to recall the color box was at one time drawn in the plot coordinates > and used to rotat around with the graph. Remember that?] All views, as you get by mouse rotations, should look good. > Then replot the 3d example after > > set xlabel 'xlabel' > set ylabel 'ylabel' > set zlabel 'zlabel' > > Again, for some viewing angles the text is way out further than it need be. > [And if you could draw the axis labels using rotated text, you might have a > real winner.] > > I think this is the more difficult task that Hans refers to: making that axes > annotation look good in all views. I wish a much simpler task: the box of "set border 4095" rotates within the bounding box adjustable by "set Xmargin". Ignore labels as tics for this size -- exactly as "set Xmargin" in 2D. How to prove it: "set l+r+b+t margin 0", "set border 4095" , and the box is tighly inside the graphics window for any rotation by mouse. --- PM |
|
From: Daniel J S. <dan...@ie...> - 2006-02-09 19:18:25
|
Petr Mikulik wrote: >> I think this is the more difficult task that Hans refers to: making >> that axes annotation look good in all views. > > > I wish a much simpler task: the box of "set border 4095" rotates within > the bounding box adjustable by "set Xmargin". Ignore labels as tics for > this size -- exactly as "set Xmargin" in 2D. I understand. That's what I'd like too. Dan |
|
From:
<br...@ph...> - 2006-02-09 16:48:45
|
Petr Mikulik wrote: >> 1) add more 'coordinate' classes for 3D plots, if only for debugging. >> We need commands like >> >> set arrow from view 0,0,0 to view 1,1,1 # 'camera' coordinates >> set arrow from canvas 0,0 to canvas 1,1 # the 'plot_boundary' > > Aha, there is no coordinate system for the bounding rectangle of the 3D? > Do we need it? I think so. It would certainly help us in modifying the layout code, and it could be useful for users, too. A 3D plot has more separate coordinate systems than a 2D one, but we only offer coordinate systems for those that also exist in 2D. > This looks like a bug: > set arrow 1 from graph 0,0,0 to graph 1,1,1 > splot x*y > pause -1 > set view map > replot > pause -1 > plot x > > I would expect a line in another diagonal. Well, I did point out that the 'set view map' implementation is an unholy mess, didn't I? >> 2) Extend boundary3d(): add handling for the other 3 margins, 'set >> offsets', and completely re-think space reservations for ticks, >> ticklabels, and axis labels. > > You mean 'set margins'? I think this is the most easy and helpful fix. > This would allow to scale down the 3D plot area manually in order to > allow enough space for the color box when needed. Scaling it further down isn't exactly the most pressing need, IMHO. The real problem are horrors like 'set view ,,1.3' many people use in an attempt to scale *up* the 3D plot area. The notion that 3D plots were not utilizing enough of the available space was a good part of the motivation of 'set view map', and look where that got us. > > --- > PM > |
|
From: Daniel J S. <dan...@ie...> - 2006-02-07 07:53:42
Attachments:
layout.png
|
Ethan A Merritt wrote: > On Monday 06 February 2006 11:00 pm, Daniel J Sebald wrote: > >>The question is: Put effort into touching up the 3d keys, >>or put effort into unifying plot layout, effectively fixing 3d keys? > > > I don't see how you *could* unify the 2D key and the 3D key. > They are intrinsically different. The 2D case has a fixed > plot border (not the canvas border, the plot border) within > which we normally position the key. 3D plots *have* no > such border except in the special case of `set view map`. I think of the plot, 2d or 3d, as having an inherent rectangular space in which it can be plot (more on zooming later). For the 3d plots currently, I assume the canvas border is the allotted region. In the attached PNG I've attempted to illustrate. The solid line is what I think you are calling canvas border. The top graph shows the plot border the same as the canvas border. The bottom graph shows that room is first made for the key and/or colorbar. The plot border is shrunk and consequently the 3d plot is shifted to the left making the layout look better than having the color bar in the plot itself. A person could always leave out the margin and manually place the key if he or she wants the plot to occupy as much space as possible. The change as far as generating the 3d plot should be trivial. I'd hope that all one need do is change the settings for the limits the 3d code uses. Now, as for zooming, I think it would be nice for the mouse to act as it currently does, but don't allow plotting outside the plot border (the dotted line) even when zooming. (A nicely place min or max should fix that problem where zooming in too far causes some lines to alias into different directions.) You've talked in several instances now of plot and canvas border. Formalizing that would be nice. (And sub-borders for for multiplot? Don't know.) In addition, if we go with the idea that there is no plot border for 3d and no margins, then the solution is not to fix the 3d key example you've given, but to disallow the words (rmargin, bmargin, etc.) in the case of 3d placement because they make no sense. Dan |
|
From: Petr M. <mi...@ph...> - 2006-02-07 10:20:19
|
> The change as far as generating the 3d plot should be trivial. I'd hope that > all one need do is change the settings for the limits the 3d code uses. > > Now, as for zooming, I think it would be nice for the mouse to act as it > currently does, but don't allow plotting outside the plot border (the dotted > line) even when zooming. (A nicely place min or max should fix that problem > where zooming in too far causes some lines to alias into different > directions.) That would be very useful to use rmargin for extending the "margin" for the key and the colorbar as your figure shows. Currently this is not possible, which does inherent problems how to draw colorbar with long tic labels and a title. This would really need to be fixed before 4.2 as we want users don't draw beyond the plot canvas. --- PM |
|
From:
<br...@ph...> - 2006-02-08 14:11:45
|
Daniel J Sebald wrote: > Hans-Bernhard Bröker wrote: >> The 3D plots do have such a border. Its real shape is not a >> rectangle, though. It's an ellipse, inside which the plot can take >> different >> orientations according to 'set view'. > > Sort of; until zooming as it currently exists is factored into the > picture. That style of zooming (the <zscale> parameter of 'set view', really) is a horrible hack, period. If ever we get a chance to do it, I strongly suggest we kill that feature and be done with it. The cost of fixing key layout is a complete overhaul of the splot layout engine. boundary3d() has become at least as complex as boundary(), probably more. The key is really only a minor aspect of the real problem. |
|
From: Jonathan T. <jt...@ae...> - 2006-02-08 14:34:17
|
On Wed, 8 Feb 2006, Hans-Bernhard Bröker wrote:
> That style of zooming (the <zscale> parameter of 'set view', really) is a
> horrible hack, period. If ever we get a chance to do it, I strongly suggest
> we kill that feature and be done with it.
Please don't do that (at least not without replacing it with equivalent
functionality elsewhere)! This parameter is ++useful to me, both for
day-to-day interactive use of gnuplot, for movies (with perl scripts
generating gnuplot commands to produce each frame), and for final
publication-quality figures.
ciao,
--
-- Jonathan Thornburg <jt...@ae...>
Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut),
Golm, Germany, "Old Europe" http://www.aei.mpg.de/~jthorn/home.html
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam |
