[ENH]: fontsize argument for colorbar

Problem

Would be nice to have a fontsize argument for plt.colorbar() that changes font size of ticks and labels. Or two separate keywords to control them independently. To change that I usually have to google how to change that property.

Proposed solution

Add a keyword plt.colorbar(fontsize=20) or plt.colorbar(size=20)?

Its ambiguous which font you would be setting. The magic command should be the same as for all axes: cb.ax.yaxis.set_tick_params(labelsize=32). I admit that is a bit of a pain, but its the same for all axes. I don't think I would be in favour of adding a different API for colorbars...

https://matplotlib.org/stable/api/_as_gen/matplotlib.axis.Axis.set_tick_params.html

You can shorten to cb.ax.tick_params(labelsize=32).

https://matplotlib.org/stable/api/_as_gen/matplotlib.axes.Axes.tick_params.html

It would be consistent with

plt.xticks()
plt.yticks()
plt.xlabel()
plt.ylabel()

And it would be good for higher level wrapper such as seaborn.

E.g.:

sns.heatmap(dataframe, cbar_kws={'label': 'log( count )', 'fontsize': 20})

Of course this could also be implemented at a higher level.

I also often find myself trying:

plt.colobar(size=20)

But is just a suggestion. If there are other concerns speaking against that then maybe not.

And it would be good for higher level wrapper such as seaborn.

Thats a reasonable point. The problem with colorbars is that they are very complex! They consist of an Axes + an active Axis + a passive Axis + a scalar mappable + a colormap + a norm. Its pretty hard to pass all the toggles on those down in a coherent fashion. For instance colorbars also have a label. Should fontsize set the label size as well? If not, do we need a separate label_fontsize? The colorbar API is already pretty convoluted, so the conservative reaction is to make folks argue hard if they want to add to it 😉

@jklymak

Agreed that it doesn't make sense to map the entire axis API up one level onto colorbars.

@jklymak re: "an axes + an active axis": perhaps it would be good for cbars to expose cbar.axes (as alias for cbar.ax -- .axes is after all standard for all artists; we don't have to deprecate .ax) and cbar.axis (i.e., the long axis) to encourage directly using them? (I don't think we really need to have an easy access to the short axis, but I may be wrong too.)

See #20350 for a proof of concept of moving Axes up a level, which would help for cases like this I think. It isn't bad from a code perspective, but it probably does expose a few too many extraneous things from the Axes namespace into Colorbars that could make it more confusing in the end.

Navigation Menu

Repository navigation

[ENH]: fontsize argument for colorbar #21674

Problem

Proposed solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[ENH]: fontsize argument for colorbar #21674

Description

Problem

Proposed solution

Activity

jklymak commented on Nov 18, 2021

timhoffm commented on Nov 18, 2021

sorenwacker commented on Nov 18, 2021

jklymak commented on Nov 19, 2021

anntzer commented on Nov 19, 2021

greglucas commented on Nov 19, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions