colorbar, again

[David Bateman]

Francesco Potorti` wrote:
> This mail follows up a mail exchange on help-octave, as this starts
> sounding as a bug.  Other users get a correct behaviour, still don't
> know on what that depends.
>
>   
>>>  pcolor(peaks()); colorbar
>>>
>>> the resulting plot is nice and good, but the colorbar on the right is
>>> too big: its height should be the same as the right axis'.
>>> Well, to be true, it is the plot that is too small: why ever all that
>>> wasted space all around?
>>>       
>
>   
>> I get the same behavior that you do.  See attached screen shot.  I'm
>> running on OS X, and I got the same behavior using aquaterm or x11.
>> See attached picture.
>>     
>
> Exactly.  This is the same picture that I get.  Find it at
>  <http://www-old.cae.wisc.edu/pipermail/help-octave/2008-September/010899.html>
>
>   
>> OS version: 10.5.4
>> Octave version: 3.0.2
>> GNUPlot version: 4.0 patchlevel 0
>>     
>
> For me:
>   
>> OS: Debian testing on amd64
>> Octave: 3.0.1
>> Gnuplot: 4.2.2
>>     
>
> Nothing changes even after going to Gnuplot 4.2.3.
>
>   

Sorry I didn't make it clear in my previous e-mail why this issue 
exists.. The 3.0.x version of colorbar is a light wrapper around a 
gnuplot colorbox. The position of the colorbox is calculated manually by 
Octave, and due to the manner that __go_draw_axes__ uses the axis 
outerposition to set the position of the plot an empirically derived 
formula for the colorbar size is used. Therefore something like

imagesc(peaks); colorbar()

will give the right colorbar size. Now pcolor is in fact a surface and 
so is a 3D plot that just has a 2-D view and the size of the window is 
different than the 2-D gnuplot windows.

The fix is to get the colorbar size calculated from the window size 
itself. This is what I've done in a patch for 3.1.51+ that is pending. 
However, I'm not sure that will even fix the issue for gnuplot as the 
manner in which it scales 3D plots relative to the size and the margins 
set by Octave is not clear.

D.