Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2004-11-08 06:31:32
|
I updated the key patch and demo. The demo is in PDF format at http://acer-access.com/~ds...@ac.../gnuplot/key.pdf The layout of the plot could use small changes here or there, but this should be a good first step toward cleanup. I'll let it sit for a few months to see what people think. Dan |
|
From: Petr M. <mi...@ph...> - 2004-11-08 08:13:23
|
> I updated the key patch and demo. The demo is in PDF format at > > http://acer-access.com/~ds...@ac.../gnuplot/key.pdf > > The layout of the plot could use small changes here or there, but this > should be a good first step toward cleanup. I like it, it provides a consistent syntax. > I'll let it sit for a few months to see what people think. Why not add it to cvs earlier if more people agree? --- PM |
|
From: Daniel J S. <dan...@ie...> - 2004-11-09 07:05:30
|
Petr Mikulik wrote: >>I updated the key patch and demo. The demo is in PDF format at >> >>http://acer-access.com/~ds...@ac.../gnuplot/key.pdf >> >>The layout of the plot could use small changes here or there, but this >>should be a good first step toward cleanup. >> >> > >I like it, it provides a consistent syntax. > > > >>I'll let it sit for a few months to see what people think. >> >> > >Why not add it to cvs earlier if more people agree? > From what I recall, originally one issue Hans raised was that I used JUSTIFY/VERT_JUSTIFY with the hope of changing that to something consistent like H_JUSTIFY/V_JUSTIFY. But he suggested not doing that because the so large number of occurrences of JUSTIFY. I changed it to what he suggested, a GPKEY_HORIZONTAL, GPKEY_VERTICAL, etc. That is where it was before this small update I made. I remember really cleaning up the key layout nicely, at least in 2D plots. So I think moving it into CVS would be alright, and perhaps a good idea at this time. I probably didn't do as nice a job in 3D because I'm anticipating a discussion at some point at how to make key, color bar, nice 3D borders (Hans' favorite), and general layout that is consistent between 2D and 3D plots (i.e., code reuse). Part of that debate would be whether to hold that off until after a 4.1 version, because there have already been so many changes since 4.0. I'll leave that up to the rest because it sounded like a lot of work to create and publish a version. (What I mean is unifying 2D/3D layout might be upsetting the apple cart a bit to much if other items have priority.) Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-11-09 18:45:06
|
On Monday 08 November 2004 11:06 pm, Daniel J Sebald wrote: > >Why not add it to cvs earlier if more people agree? I like it. There is one issue I am unhappy about, but it was not introduced by this patchset. The centering algorithm for "set key under" is very fragile, and sometimes comes out horribly wrong. See, for instance, the last plots in histograms.dem. On X11 with font "verdana,11" the key is more or less OK, although not perfectly centered. But with 'set term png font "verdana" 11' (same font) the centering is very wrong. Any chance that while this code is still fresh in your mind, you could have another look at the centering algorithm? Feel free to rip out any of my previous tweaks, since clearly they are not working reliably. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-11-10 01:11:11
|
On Tuesday 09 November 2004 03:57 pm, Daniel J Sebald wrote: > > Something else I've noticed about the way the key is laid out... If you > look at the last example of the histograms, you'll see that the sample > length (i.e., samplen) is constant for all columns. In some ways that > looks nice, but in some ways it also uses a lot of space. That is, the > "United Kingdom" entry determines the width of _every_ column. I wonder > how it would look if the default, non-samplen-specified layout would > allow those columns to vary, so that the Denmark/Norway column etc were > moved over. We must not lose track of the most important point, however, which is that the caption is supposed to match the figure. In the ideal case for histograms like this one, I would want each column of the key to start exactly under the corresponding set of histograms. At the very least I would like a guarantee that if the histograms come in sets of, say, 3+2+3 then the key columns also contain 3, 2, and 3 entries correspondingly. > The modified key at first seems rather difficult, but perhaps not. > Rather than algrebra, an exhaustive attempt at layout could be done. > Of course, I don't think we want a complete exhaustive search in that > we could rearrange the order of the key entries. (Although I bet > something creative could be done whereby one first orders the key > samples by width... but .) Rather, one would begin by attempting to put > all samples on a row (column). If they don't fit, then one starts there. If you can figure out a smarter automatic method, great. But I'd settle for the much simpler alternative of some flag that forces a column break. In the case of histograms, I'd like the "newhistogram" command to force such a column break. In the general case there would have to be some user-accessible flag or option. Maybe set key columns=(3,3,2) which means generate a new column after the 3rd, 6th, and 8th entries. This would need some further thought. Does one count or not count plots with 'notitle'? -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Daniel J S. <dan...@ie...> - 2004-11-10 02:05:15
|
Ethan Merritt wrote: >On Tuesday 09 November 2004 03:57 pm, Daniel J Sebald wrote: > > >>Something else I've noticed about the way the key is laid out... If you >>look at the last example of the histograms, you'll see that the sample >>length (i.e., samplen) is constant for all columns. In some ways that >>looks nice, but in some ways it also uses a lot of space. That is, the >>"United Kingdom" entry determines the width of _every_ column. I wonder >>how it would look if the default, non-samplen-specified layout would >>allow those columns to vary, so that the Denmark/Norway column etc were >>moved over. >> >> > >We must not lose track of the most important point, however, which is >that the caption is supposed to match the figure. In the ideal case >for histograms like this one, I would want each column of the key to >start exactly under the corresponding set of histograms. At the very >least I would like a guarantee that if the histograms come in sets of, >say, 3+2+3 then the key columns also contain 3, 2, and 3 entries >correspondingly. > Oh! Now I see why the X11 example, which is a 2 x 5 key, has the strange space at locations (2,2) and (2,4). I wasn't aware it was supposed to work that way. >>The modified key at first seems rather difficult, but perhaps not. >> Rather than algrebra, an exhaustive attempt at layout could be done. >> Of course, I don't think we want a complete exhaustive search in that >>we could rearrange the order of the key entries. (Although I bet >>something creative could be done whereby one first orders the key >>samples by width... but .) Rather, one would begin by attempting to put >>all samples on a row (column). If they don't fit, then one starts there. >> >> > >If you can figure out a smarter automatic method, great. >But I'd settle for the much simpler alternative of some flag that >forces a column break. In the case of histograms, I'd like the >"newhistogram" command to force such a column break. In the general >case there would have to be some user-accessible flag or option. >Maybe > set key columns=(3,3,2) >which means generate a new column after the 3rd, 6th, and 8th entries. >This would need some further thought. Does one count or not count >plots with 'notitle'? > Well, this is interesting. I'd say I'm not completely sold on the idea of having the key behave uniquely different for the plot style of grouped histograms. So, some way of controlling the key seems in order; something general. One thing that threw me in the plot--that made me not conclude the key samples should be associated with each cluster of bars--is the fact that it is one key. Wouldn't you prefer multiple boxed keys? Say as in the mock up: http://acer-access.com/~ds...@ac.../gnuplot/sample_2_keys.png Would it be easier to program something allowing multiple keys rather than the grouping or clustering of columns within a single key? With that, one could plot things in groups, whether it be histograms, lines, etc. My guess is that programming multiple keys wouldn't be too bad. However, the syntax would be something tricky. Perhaps: set key <...> set key 1 <...> set key 2 <...> unset key 2 <...> These are the sorts of commands for declaring multiple keys. (The "set key" without a number is the same as "set key 1".) But the big question is how does one make a connection between what is on the plot and how it ends up in the key? Maybe: plot 'this.file" u 1:2 key 1, 'this.file' u 1:3 k 1, 'that.file' u 1:2 key 2, 'that.file' u 1:3 k 2 Good? Bad? Dan |
|
From: Daniel J S. <dan...@ie...> - 2004-11-10 02:11:28
|
Daniel J Sebald wrote: > plot 'this.file" u 1:2 key 1, 'this.file' u 1:3 k 1, 'that.file' u 1:2 > key 2, 'that.file' u 1:3 k 2 > > Good? Bad? And I'd say that to get the keys in three different locations under the bar clusters would require manual placement of all keys. Otherwise, if all were specified as "under" then they'd land on top of one another. Dan |
|
From: Ethan M. <merritt@u.washington.edu> - 2004-11-10 02:18:02
|
On Tuesday 09 November 2004 06:06 pm, Daniel J Sebald wrote: > One thing that threw me in the plot--that made me not conclude the key > samples should be associated with each cluster of bars--is the fact that > it is one key. Wouldn't you prefer multiple boxed keys? Say as in the > mock up: > > http://acer-access.com/~ds...@ac.../gnuplot/sample_2_keys.png Absolutely! That would be great. I had been fumbling my way towards recoding the key layout so that it was generic, and then allowing multiple keys. My intent was to modify the 'set key' command to: set key {<n>} ... And allow each plot to specify which key it's title was placed in: plot 'foo' with lines key 1, 'bar' with lines key 2, 'blech' key 1 > My guess is that programming multiple keys wouldn't be too bad. > However, the syntax would be something tricky. Perhaps: > > set key <...> > set key 1 <...> > set key 2 <...> > unset key 2 <...> > > These are the sorts of commands for declaring multiple keys. (The "set > key" without a number is the same as "set key 1".) > > But the big question is how does one make a connection between what is > on the plot and how it ends up in the key? Maybe: > > plot 'this.file" u 1:2 key 1, 'this.file' u 1:3 k 1, 'that.file' u 1:2 > key 2, 'that.file' u 1:3 k 2 You and I are on the same wavelength on this one. I wasn't progressing very fast on the project, however. Mostly I had just been trying to collect all the variables having to do with the key layout into a single structure, so that later on I could have multiple such structures to support multiple keys. That was a while ago. I got sidetracked by the string variables code. -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
