Re: Plot placement, revisited

[Hans-Bernhard B. <br...@ph...>]

On Fri, 23 Jul 2004, Daniel J Sebald wrote:
> Hans-Bernhard Broeker wrote:

> >It doesn't strictly have to be zero.

> Oh.  I didn't know that.  Or I did but didn't make the connection. 
>  There is still a bit of uncertainty, isn't there?  If I specify the 
> margin to 1, for example, I'm not sure what the character height is in 
> terms of plot units.  Hence, subtract that unknown quantity from the 
> plot size and the size ends up with some uncertainty.

Depends on what it is you're trying to do.  That quantity is
terminal-dependant, yes, but not really unkown.  And it's fixed for the
time being.  So it depends on whether you want the graph box exactly in
some particular physical size, or just want to fix it in place from one
plot to the next.  Multiplots are a tricky business of their own, then.

From a formal viewpoint, requesting the graph box in any fixed size
positions, independent of how many decorations surround it, is bound to
lead to sub-optimal or broken plots one way or the other for at least some
of the terminals: if the output page size is not controllable by gnuplot
(e.g. for printer terminals), and you fix the graph box on top of that,
you'll either have elements of the plots fall off the page, or leave
undesirably large margins, as the amount of decoration in the margins
varies.

[set key below...]

> That isn't the behavior I see.  No matter what value of bmargin I use, 
> the height of the plot becomes shorter when "set key below" is used. 

Hmmmm... yes, a bug.  The vertical order of things apparently is

	graph box
	x tics
	bmargin
	key below

key below and bmargin should trade places.  Which means someone will
have to go into boundary() and fix this.  That's about the scariest
function in all of gnuplot.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.