Re: Bugs in new key placement code

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

Petr Mikulik wrote:
> Thus, there exists a bounding rectangle of that ellipse/circle. This 
> could be manipulated by all of the set margin's, not only the lmargin. 
> Isn't this functionality feasible to add?

Sure.  boundary3d() can use a lot of improvement.  Only question is: do 
this incrementally, risking an end state that is a rather tangled mess, 
or allow someone the time to really work on this, and get it _right_?

Things that really need doing in this area:

1) add more 'coordinate' classes for 3D plots, if only for debugging. 
We need commands like

	set arrow from view 0,0,0 to view 1,1,1  # 'camera' coordinates
	set arrow from canvas 0,0 to canvas 1,1  # the 'plot_boundary'

to analyze what actually goes on in 3D layout.  The main problem with 
the current layout is that even among us, the developers, nobody really 
knows what goes where, and why, in 3D, because none of the relevant 
boundaries can easily be displayed on the plot.

2) Extend boundary3d(): add handling for the other 3 margins, 'set 
offsets', and completely re-think space reservations for ticks, 
ticklabels, and axis labels.

3) Completely re-do the implementation of 'set view map', getting rid of 
temporary overrides of 'set' values for ranges, reverse states etc.  The 
number of places the value of splot_map is checked is well beyond the 
acceptable.  We've been piling band-aids upon kludges upon hacks to 
implement this feature.  That has to stop.

4) get rid of the internal surface_scale variable and all it entails. 
Obsolete <scale> parameter in 'set view', achieve its effect in other ways.

5) same as 4), for surface_scale_z --- that one's just plain wrong.

6) While at it, add point-perspective projection.