Re: patch to be applied to default or stable ?

[Ben Abbott]

On Jan 28, 2012, at 12:52 PM, Ben Abbott wrote:

> On Jan 28, 2012, at 12:36 PM, John W. Eaton wrote:
> 
>> On 28-Jan-2012, Ben Abbott wrote:
>> 
>> | > Looking at this today, if I do
>> | > 
>> | >  print test.eps '-S1024,768'
>> | > 
>> | > the bounding box in the eps file is set to 1024x768, but the size of
>> | > the plot does not fill the bounding box.  Instead, it is in the top
>> | > left corner of the page and occupies about 1/4 of the page area.
>> | > 
>> | > Is that the correct behavior?
>> | > 
>> | > jwe
>> | 
>> | 
>> | No that's not correct. 
>> | 
>> | I see what you describe using fltk, but gnuplot is working correctly
>> | for me. I assume you only see this for fltk ?
>> 
>> Yes, it seems to work correctly for me with gnuplot.
>> 
>> jwe
> 
> I reverted to ...
> 
>               http://hg.savannah.gnu.org/hgweb/octave/rev/df695e37d404
> 
> ... and the fltk result fills the bbox for me.
> 
> The height of the bbox is tall by 2 points 
> 
>       %%BoundingBox: 0 0 1024 770 
> 
> I'll start bisecting to see if I can isolate the changeset that caused the 
> regression.
> 
> Ben

John,

I'm able to fix the problem. I've been reverting your reversion below and 
thought it was a MacOS X only thing.

        
http://hg.savannah.gnu.org/hgweb/octave/diff/1367f2db49a2/src/graphics.cc

With the sources up to date and reverting this specific changeset, the fltk 
output works correctly for me.

If you apply the simple change below, does the fltk toolkit work as expected ?

diff --git a/src/graphics.cc b/src/graphics.cc
--- a/src/graphics.cc
+++ b/src/graphics.cc
@@ -3245,9 +3245,9 @@
     {
       Matrix old_bb, new_bb;
 
-      old_bb = get_boundingbox ();
+      old_bb = get_boundingbox (true);
       position.set (v, true, do_notify_toolkit);
-      new_bb = get_boundingbox ();
+      new_bb = get_boundingbox (true);
 
       if (old_bb != new_bb)
         {

Ben
Ben