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 otherAnchoredOffsetBox objects aroundaxes and aroundgridspecs.

Also a mechanism for adding arbitrary text around theaxes orgridspecs. 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 callax.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 acceptax.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 intooffsetbox 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 andshare_y are a bit complicated.

tight_layout differentiates between space between the subplots and the space around all the subplots (i.e.h_space andleft). Here I don't, I just haveleft_margin andright_margin and they are the same for all subplots. Soconstrained_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 seeshare_x andshare_y are only accessible viafigure.subplots(). So, this isn't a problem for generalgridspec-derived axes added withfigure.add_axes.

Seeoffsetbox.VPacker andoffsetbox.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 toAnchoredOffsetbox that control the location, namely;

• loc
• bbox_to_anchor
• bbox_transform
• borderpad

And so it seems likeAnchoredOffsetbox was designed in an environment that lacked a layout manager. With a layout manager in place, perhaps a newConstrainedOffsetbox 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 useAnchoredOffsetbox and never be accommodated inside the subplotspec? Or can it be changed to use theConstrainedOffsetbox, with appropriately deprecated parameters? I have no good answer.

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

[1]here,here,here andhere

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

I think it'll be possible to haveAnchoredOffsetbox (or a modified version) behavior the way you'd like. I can tackle this once I getsharex andsharey 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.

Seelayoutbox.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 thatOffsetBox children are already included inaxes.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 thatLegend should be added toaxes.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 examplesabove. Your first two examples work fine w/o any fiddling.

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 intocolorbars.py. Similarlysuptitle 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 likegs = GridSpec(2, 2),gs.stack_right(newartist, align='v_center'). This would take some thought, however, because what if I want to stack somethingelse to the right ofnewartist?

test_pickle fails becausekiwisolver 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 stackingtext andoffsetboxes 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 spineposition and the axestightbbox, which includesAnchoredBoxes.

However, we'd need an API for theGridSpec level. So far, I've mostly just worked with the existing API. Actually implementing the stacking is pretty trivial: seesuptitle orcolorbar. I think adding an external API tolayoutbox 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 togridspec where it really belongs.

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

@has2k1 How about this for an API:

Right now we can doax.add_artist(anchored_box). I'd proposed we add a method toGridSpec 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 whatbbox_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 anew 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 factthis 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 thedo_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 inkiwisolver. This is now fixed innucleic/kiwi#40kiwisolver/master, so this test should run.

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

I need to change the architecture to only attach kiwisolver variables ifconstrained_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. inFigure.__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 theset_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 toax.set_position that needed to be changed toax._set_postion. Calling the former turnsconstrainedlayout 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 allowsset_aspect to still do its thing.

• made thelayoutbox 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... 🦆