Re: Bugs in new key placement code

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

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