Re: Bugs in new key placement code

[<br...@ph...>]

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.