[Octave-bug-tracker] [bug #31610] Text in subplot overlaps

[Konstantinos Poulios]

Follow-up Comment #7, bug #31610 (project octave):

Concerning the "replace" option, you are right, there was an error in my test
case. Actually octave's subplot(r,c,n) corresponded to ML's subplot(r,c,n,
'align') and not subplot(r,c,n, 'align', 'replace') as I wrote before.

The "replace" option as implemented in your attached patch also seems to work
as expected.

Concerning the solution #3 that you have implemented, it solves the problem
with title overlapping in the gnuplot backend quite well but its behavior is
not totally compatible with ML and besides that it doesn't work with the fltk
backend, since this one doesn't take into account the
"ActivePositionProperty".

Actually, as you have pointed out, ML seems to use some kind of callback to
calculate the size of all axes in a grid. If you try

subplot(221)
subplot(222)
subplot(223)
subplot(224)
xlabel('me')

in ML you will see that the xlabel command affects not only the subplot 224
but also the subplots 221,222 and 223.

I think that at least for the fltk backend it shouldn't be very difficult to
scan all subplots in a figure and synchronize the sizes of those that belong
to the same grid (e.g. grid 22 in the example above).

I am not sure if there is already a possibility for the fltk backend to add
some extra padding space around the axes box manually. If not, maybe we could
provide the possibility of extra padding space in the get_boundary function of
the axes object. Maybe this is also the place where the
"ActivePositionProperty" could also be implemented. What do you think?

Before trying to fix anything, I will try to understand the previous work of
David Batemann with respect to the colorbox issues which seem to be relevant.

One possibility would be to provide a quite ML-compatible behavior for the
subplots in the fltk backend and just use your solution #3 for the gnuplot
backend. Would such a backend-depended handling of subplots be an acceptable
solution?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?31610>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/