Re: key patch update

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

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