Re: Bugs in new key placement code

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

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