I am interested in the specifics of how the legend will be constrained. Perhaps through an easily extensible mechanism that can be used to add other AnchoredOffsetBox objects around axes and around gridspecs.

Also a mechanism for adding arbitrary text around the axes or gridspecs. This would be hand in adding captions to plots.

@has2k1 Thanks.

I want to make sure I understand the desired behavior. We are getting into use cases I haven't ever needed for my personal plotting needs, so this is where I need help with what people envision.

Are you hoping that if I call ax.legend(loc='center left', bbox_to_anchor=(1., 0.5)) then the layout manager will automatically make the axis object to accommodate the legend inside the subplotspec? But it should also accept ax.legend(loc='center left', bbox_to_anchor=(0.5, 0.5))?

I think thats doable, but I need to think about how that gets implemented. Right now I just implement nested layouts and adjacent layouts w a pad. Arbitrarily displaced in axes co-ordinates is doable, but not implemented yet. I don't see why a subplotspec can't contain more than one child that also have displacements relative to their widths.

I need to dig into offsetbox to see how to make it extensible to other offset boxes. Can you point me to an example of other uses beyond legend so I can test?

share_x and share_y are a bit complicated.

tight_layout differentiates between space between the subplots and the space around all the subplots (i.e. h_space and left). Here I don't, I just have left_margin and right_margin and they are the same for all subplots. So constrained_layout doesn't cover the often-used case of just labelling the outside rows and columns (it works, but it introduces a lot of extra white space between subplots).

As far as I can see share_x and share_y are only accessible via figure.subplots(). So, this isn't a problem for general gridspec-derived axes added with figure.add_axes.

See offsetbox.VPacker and offsetbox.HPacker for ideas.

Are you hoping that if I call ax.legend(loc='center left', bbox_to_anchor=(1., 0.5)) then the layout manager will automatically make the axis object to accommodate the legend inside the subplotspec?

Yes.

But it should also accept ax.legend(loc='center left', bbox_to_anchor=(0.5, 0.5))?

Yes again. But I fear it would make the code complicated as it would mix two layout mechanisms. There are already four parameters to AnchoredOffsetbox that control the location, namely;

• loc
• bbox_to_anchor
• bbox_transform
• borderpad

And so it seems like AnchoredOffsetbox was designed in an environment that lacked a layout manager. With a layout manager in place, perhaps a new ConstrainedOffsetbox can also serve as a container for other Offsetboxes. But this course of action would conflict with the first question above. i.e does the legend still use AnchoredOffsetbox and never be accommodated inside the subplotspec? Or can it be changed to use the ConstrainedOffsetbox, with appropriately deprecated parameters? I have no good answer.

Plotnine extensively [1] uses offsetboxes for the legends and it has very finicky parts. Here is a simplified version that demonstrates a custom legend system similar to the one in plotnine.

[1] here, here, here and here

@has2k1 Thanks a lot for the examples. That helps.

I think it'll be possible to have AnchoredOffsetbox (or a modified version) behavior the way you'd like. I can tackle this once I get sharex and sharey to work.

@has2k1 this now makes space for legends. Since it actually queries the underlying _legend_box, which is an AnchoredBox, this is easily extensible to other cases. However, given that anchoredBox objects usually seem to be buried as implementation detail in other classes, my guess is the best thing is to have the checks on those classes rather than AnchoredBox directly. i.e. Legend isn't an AnchoredBox, but it uses one for its layout.

See layoutbox.get_axall_tightbbox for the logic here.

legend is a bit flakey as positions get set at the draw sequence, so for perversely large legends a resize is needed to make the legend fit properly. However, I think the method often yields a decent result.

legend is a bit flakey as positions get set at the draw sequence, so for perversely large legends a resize is needed to make the legend fit properly. However, I think the method often yields a decent result.

I have encountered a related issue when creating an Animation class for plotnine. It may complicate animations, but on the whole specified figure sizes that are just rough estimates final sizes are a worthy price for a good layout. After all, tight_layout() has been an offender already.

@has2k1 Note that OffsetBox children are already included in axes.get_tightbbox:

for child in self.get_children():
 if isinstance(child, OffsetBox) and child.get_visible():
 bb.append(child.get_window_extent(renderer))

It almost seems that Legend should be added to axes.get_tightbbox as a possible child that would expand the bbox.

See issue: #9130

Removed [WIP]. I think this works, but I'm sure there are edge cases I haven't found.

kiwisolver is now on pypi:: pip install kiwisolver installs 1.0.0 and works here. I'm not 100% sure how to incorporate it into the matplotlib setup.py as a dependency.

@has2k1 Just to follow up on your legend examples above. Your first two examples work fine w/o any fiddling.

figure_2

The third example, where you want a global legend doesn't work, and indeed makes the layout collapse in on itself. I'm not sure how to handle this, as you specify the anchored box in figure co-ordinates, but anchor it to one of your subplots, ax1. The constrained_layout then uses the whole area taken up by ax1 and the legend to determine the area the layout needs. That leaves no room for the other subplots, and the whole thing fails.

Right now I have "global" colorbars stacked to the right of the gridspec that contains the relevant subplot specs (or to the left, bottom etc). This is hard coded into colorbars.py. Similarly suptitle is stacked over the parent gridspec inside the figure container. However, it seems to me that something more generic might be a future enhancement. Maybe something like gs = GridSpec(2, 2), gs.stack_right(newartist, align='v_center'). This would take some thought, however, because what if I want to stack something else to the right of newartist?

test_pickle fails because kiwisolver objects can't be pickled, and they are now attached to all the other objects.

The way the plot in the third example is constructed need not be how it should be done. In fact, using figure coordinates is part of the problem.

Maybe something like gs = GridSpec(2, 2), gs.stack_right(newartist, align='v_center'). This would take some thought, however, because what if I want to stack something else to the right of newartist?
This is what I have had in mind too. The ability to stacking text and offsetboxes to the sides of the axes and the gridspec(s).

I have looked a little at what you currently have in place with the goal of making it extendable. i.e. For the
SubplotSpec, GridSpec and Figure layoutboxes, define regions to contain additional items (text & offsetboxes) for stacking.

 [top]
 ----------
 | |
 [left] | | [right]
 | |
 | |
 ----------
 [bottom]

I have looked a little at what you currently have in place with the goal of making it extendable. i.e. For the SubplotSpec, GridSpec and Figure layoutboxes, define regions to contain additional items (text & offsetboxes) for stacking.

For SubplotSpec its pretty much done because it works on the difference between the spine position and the axes tightbbox, which includes AnchoredBoxes.

However, we'd need an API for the GridSpec level. So far, I've mostly just worked with the existing API. Actually implementing the stacking is pretty trivial: see suptitle or colorbar. I think adding an external API to layoutbox is a reasonable way to go. I think you'd want something like

• figlayout.gridspec_stack_right(gs, newartist)
• figlayout.gridspec_stack_bottom(gs, newartist), etc
  However, one could also imagine adding such an API to gridspec where it really belongs.

Edit: ...and do these artists then get layoutbox properties?

@has2k1 How about this for an API:

Right now we can do ax.add_artist(anchored_box). I'd proposed we add a method to GridSpec so we can call: gs.add_anchoredbox(anchored_box) That would entail the GridSpec having a bbox, but that doesn't seem to onerous. I'm a little fuzzy on what bbox_transform will be required to make this relative to the gridspec box, but I think its doable.

That seems the most flexible, and consitent with an API folks will already know.

Yes an API of the the form gs.add_anchoredbox(anchored_box) is simple and straight forward. I agree with the fuzziness around some of the parameters of the anchored_box. The solution may be a new offsetbox (the 2nd point)

A GridSpec that properly encloses an offsetbox of some kind will make composing/arranging multiple plots a lot easier. Packages that use MPL will get a lot more interesting, in fact this feature would rely on it.

I am trying to get up to speed with what you have so far, but despite the plentiful comments I hit a road block on the do_constrained_layout function.

@has2k1 Fair enough. I'll try and improve the comments. There may even be obsolete comments in there...

I was hoping I could add comments from a third party perspective immediately after I understood what was going on.

@has2k1 That would be fabulous. I just pushed a commit that improved a bit of the doc, and removed the obsolete document bits. Let me know if you have questions, or I can point you towards tests that show how the different parts work. It was all more subtle than I originally thought it would be.

docs-python27 fails with a unicode error in kiwisolver. This is now fixed in nucleic/kiwi#40 kiwisolver/master, so this test should run.

The pickle test is always going to fail for matplotlib instances that attach kiwisolver variables because they can't be pickled. Does anyone use pickling with matpotlib? I admit I liked using pickle until I found out that its not compatible from py2.7 to py3.6 and I had to translate a bunch of old pickles.

I need to change the architecture to only attach kiwisolver variables if constrained_layout == True, and then just say that constrained_layout won't work with pickeled plots. Unless someone knows how to serialize kiwisolver variables.

Haven't followed the discussion at all, but re: pickling, you can perhaps remove the kiwisolver instance at pickle time (we already to that e.g. in Figure.__getstate__ (or grep for __getstate__ through the codebase to see how this is done).

Does anyone use pickling with matpotlib?

Yes, a surprising number of people. When we break this we find out rapidly.

Got it. Interesting interaction - I haven't played with interactive plotting much yet, except to change plot window size. This is clearly a bug in the set_aspect interaction. Hopefully not a big deal to fix...

I found another interactive glitch. Make a minimal plot:

fig, ax = plt.subplots(constrained_layout=True)
ax.set_xlabel('X label', fontsize=20)
ax.plot([0, 1])

Now click the zoom/pan button and fiddle with the view limits. Then click the home button. Now the constraint management is no longer in effect: reducing the window height by dragging up the bottom chops off the bottom of the legend.

@efiring - thanks a lot - try the latest commit.

The second issue was some missed calls to ax.set_position that needed to be changed to ax._set_postion. Calling the former turns constrainedlayout off.

The first issue was that I was setting both positions when I set the position in constrained layout. Setting only the original is the way to go, and allows set_aspect to still do its thing.

• made the layoutbox objects private attributes of the various axes/figure/gridspec/subplotspec classes...

squash + rebase

The other nitpick is just an irritant, the dots after the numbers i.e 0., 1.. I'm not used to seeing them in python code.

I think if you don't do that in some languages you force integer arithmetic, which can be very unfortunate. i.e. 3./10. neq 3./10 Nice that doesn't happen in python, I'll try and find most instances and clean up.

Thanks for the review @has2k1 I think I addressed most of your suggestions. Let me know about the pop/del thing.

Rebase...

I'm going to make an executive decision and merge this

• It adds a major feature we have been talking about for years
• need to get lots of users to see where it breaks 😈
• is strictly opt-in
• mostly new code, unlikely to break anything

Thanks @jklymak and everyone who put effort into reviewing this (particularly @has2k1 , @anntzer and @efiring )!

Thanks a lot everyone! Now here comes the bug reports... 🦆