Re: autoscale.dem failing, left margin not working

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

On 03/13/2011 11:33 PM, Ethan Merritt wrote:
> On Sunday, March 13, 2011, Daniel J Sebald wrote:
>> On 03/12/2011 01:09 PM, Daniel J Sebald wrote:
>>> On 03/12/2011 12:36 PM, Ethan Merritt wrote:
>>>> On Saturday, March 12, 2011, Daniel J Sebald wrote:
>>
>>>>> A second issue is that the left margin no longer works properly.  Try
>>>>> the 'key.dem' demo and it should be apparent.  There are some other
>>>>> demos where the plot edge for the left margin is not computed correctly.
>>>>
>>>> I haven't found any where the left margin of the plot itself is incorrect.
>>>> The placement of the key box is non-obvious or incorrect in some of the
>>>> examples. Not sure whether this is because it's mis-estimating to left
>>>> margin or the font size or what.
>>>
>>> This issue is still present.  It must have come about before 4.4.
>>>
>>> Check the example with "Key (out vert left top)" as a title of the
>>> upper-left sub-plot.  The key used to be outside the actual sub-plot,
>>> but the sub-plot margin is too small.  It should look like a mirror of
>>> the example "Key (out vert right top)".
>>
>> I think it is this change:
>>
>> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/graphics.c?r1=1.316&r2=1.317
>>
>> specifically the green line added at the start of the diff list.  I
>> commented out that line and the key demo works as I remember.
>
> I take it you are refering to addition of the line
>
>
>           plot_bounds.xleft = xoffset * t->xmax;
>
>
>
> It looks to me that the program flow is currently
>   - preliminary calculation of xleft, xbot, etc
>   - calculation of key box size
>   - add key box size where needed
>   - calculation of tic label sizes
>   - recalculate xleft, xbot, etc now using the tic label sizes
>   - oops the key box wasn't added in again
>
> It may be that the key box size has to be added in twice,
> once for the preliminary calculation and once for the final
> calculation.  Or it may be that it only has to be included
> in the final calculation, whereas right now it is only included
> in the preliminary calculation.
> I'm not sure which fix is correct.

The way I looked at it, when the key is outside (that's the case where 
this is important), its presence effectively shrinks the region for the 
plot.  I guess that is how the tic labels work as well.  xleft, etc. 
should be adjusted relative to their current values whenever a new item 
is added outside its boundaries, I would think.

 From what I recall, there is a lot of code for setting the plot 
locations, and justifiably so.  But it was difficult to follow and in 
some cases may have duplicate code.  As a result it feels a bit like 
trial and error getting layout right.  What's needed is a outline, as 
you've listed above.  I'm not sure it is worth trying to clean this up 
until the day comes for multiple keys.  Not poorly written; just big.

Dan