8000 [ENH]: Add Independent xlabelpad and ylabelpad Options to rcParams · Issue #28860 · matplotlib/matplotlib · GitHub
[go: up one dir, main page]
Skip to content

[ENH]: Add Independent xlabelpad and ylabelpad Options to rcParams #28860

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
NominHanggai opened this issue Sep 21, 2024 · 5 comments
Open

[ENH]: Add Independent xlabelpad and ylabelpad Options to rcParams #28860

NominHanggai opened this issue Sep 21, 2024 · 5 comments
Labels
New feature

Comments

@NominHanggai
Copy link

Problem

Currently, we can only set a uniform axes.labelpad, which applies the same padding for both the x-axis and y-axis labels.

I am aware that it is possible to adjust the labelpad for the x and y labels independently using set_xlabel(..., labelpad=x_pad) and set_ylabel(..., labelpad=y_pad) in plotting code. However, would it be better to add separate options in rcParams to set the padding for x and y labels independently, similar to how xtick.major.pad and ytick.major.pad work?

Proposed solution

No response
@timhoffm
Copy link
Member

While fundamentally reasonable, this is a bit more complicated because we need to keep backward compatibility with axes.labelpad.

We do have xaxis.labellocation / yaxis.labellocation. So the proper place would be xaxis.labelpad / yaxis.labelpad. But since we already have axes.labelpad it's a bit more difficult to handle consistently. One needs to define precedence rules so that existing use cases are not broken. Any implementation attempt must be aware of this.

@Kaustbh
Copy link
Contributor
Kaustbh commented Feb 10, 2025

Hi @timhoffm, I’d love to give this a try while ensuring backward compatibility by implementing clear precedence rules.

@timhoffm
Copy link
Member

@Kaustbh this should best build on top of the precedence mechanism added to _val_or_rc() introduced in #29481.

Unfortunately, we currently have a significant review backlog, which is why that PR is not yet in and the mechanism cannot be used. But you could start from that branch and rebase when that PR gets merged.

@Kaustbh
Copy link
Contributor
Kaustbh commented Feb 16, 2025

Okay I will start working on it.

@Kaustbh
Copy link
Contributor
Kaustbh commented Mar 12, 2025 •
edited
Loading

Hi @timhoffm I have added the new rcParams, just waiting for the PR #29481 to get merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
New feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@timhoffm @NominHanggai @Kaustbh
0