Do you think the same should be available for supx/ylabel? (From an implementation perspective it may actually be simpler...)

Anyone who wants to do this will want to make sure there is still a way for constrained_layout to work.

I think this is a good first issue because there is limited API choices to be made and there are good examples of merged PRs adding rcparams to follow, but medium because there are a bunch of moving parts that will need to be done:

• add the validators for the rcaparms
• add the values to the default matplotlibrc
• add tests that changing the rcparams works and overridding it at call time works
• add a "whats new"
• maybe add an example or extend an existing example to make use of the new rcparams

@jklymak could you comment on why this would conflict with constrained layout? If we can already control these things through kwargs I would not expect making them controllable via rcparam to cause any (new) problems.

Note that docstrings are autogenerated via a common template for suptitle, supxlabel, supylabel and parameter defaults are substituted. This would need adption to include the rcParams for suptitle, which will be a bit fiddly.

Naming: I propose to use figure.title_horizontalalignment instead of figure.titleha. We should not be using abbreviations for the rcParams. While most of the names do not include underscores figure.titlehorizontalalignment seems too unreadable, and we have precedence for underscores, e.g. in legend.title_fontsize.

If the scope is as explained by @tacaswell 's comment, I would like to take this up. Might need a little help to make sure what'll be the correct starting point though. Not sure about the constrained_layout issue though?

Tim's comment also needs to be fully addressed.

Yep, that too. I know a little less about it but should be able to pick it up! :)

#24031

I was taking a look at this PR. Is there any other example I can refer to?

As @oscargus mentioned, doing it for supx/ylabel makes it much easier to implement and that should also take care of the docstrings if I understand right? Since then we won't have to have different things for suptitle and supx/ylabel. So should I work on having it for all three or do we want to do it just for the title?

Sorry there is no issue with constrained layout. The issue is with aligning the x/ylabels and the title. We need a sentinel for "default location" which has historically been the default location. Then we allow ourselves to move the label to avoid any ticks or other inner decorations. For xlabel and title this only affects the y and for glabelle this only affects the x.

If the user sets the y value for the title to something other than the default, we respect that value and don't try to adjust.

If we make these things have rcparams do we respect the values passed or do we assume the user still wants the automatic shifting of the title if the y value is equal to their rcparam default?

Thanks, @jklymak ! I think I understand what you mean. But in that case, if the user is asking to use a constrained layout, doesn't that by itself imply that they're fine with the locations changing to achieve the constrained layout? In my mind, this is similar to layout="constrained" having the highest priority, followed by the value passed as an argument, with rcparam value being the least priority but default.

My comment has nothing to do with constrained_layout, but rather to do with the automatic placement of the labels.

Ohh my bad. Sorry. In that case, I think the set rcparam value comes with the understanding that automatic placement still happens to make the figure clear. I don't think that would be something undesirable by the user.

I was taking a look at this PR. Is there any other example I can refer to?

#22566 added another set of rcparams for suptitle/supxlabel/supylabel so it may be worth checking, especially how to get the docs to generate correctly. Which is also why I claimed that it may be easier to add something similar to supxlabel and supylabel as well, although not sure that one would like to have the same alignment for both (figure.xlabel_horizontalalignment etc ?).