octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: figure positioning problem


From: John W. Eaton
Subject: Re: figure positioning problem
Date: Mon, 21 Nov 2011 01:41:18 -0500

On 19-Nov-2011, Michael Goffioul wrote:

| On Sat, Nov 19, 2011 at 4:18 PM, John W. Eaton <address@hidden> wrote:
| > Do you mean the following change?
| >
| > diff --git a/src/graphics.cc b/src/graphics.cc
| > --- a/src/graphics.cc
| > +++ b/src/graphics.cc
| > @@ -3237,9 +3237,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)
| >         {
| 
| Yes, that's what I mean.
| 
| > If so, then yes, this avoids the problem for me.  But then the figure
| > that I'm working with is also not resized in the way I think it is
| > supposed to be.  So instead of the figure window being tight around
| > the axes objects, there is a lot of whitespace padding.  But at least
| > the axes are fully within the figure window.
| >
| > Should I make this change?
| 
| Yes. The current code is wrong: it'll use the external boundingbox,
| which is not defined/set by the FLTK (or gnuplot) backend. So
| basically, the test (old_bb != new_bb) will never be true (changing
| the position property will not change the outerposition, so the
| computed external bounding box will still be the same).
| 
| If it still doesn't do what you want, there might be another problem.
| But at least the change above fixes the problem I've introduced when
| adding the outerposition property.

I checked it in.

Thanks,

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]