Skip to content

[Bug]: title position incorrect for polar plot #29381

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.

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

Closed
jkittner opened this issue Dec 27, 2024 · 6 comments · Fixed by #29382
Closed

[Bug]: title position incorrect for polar plot #29381

jkittner opened this issue Dec 27, 2024 · 6 comments · Fixed by #29382
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. status: confirmed bug
Milestone

Comments

@jkittner
Copy link

Bug summary

When using a polar coordinate system the plot title overlaps with the axis labels. This worked in 3.9.4 and broke with 3.10.0. This commit broke it: 8abe308 via #28300

Code for reproduction

import matplotlib.pyplot as plt

plt.polar([0, 1], [0, 1])
plt.title('My Title')
plt.savefig('output.png')

Actual outcome

The title overlaps the axis labels

grafik

Expected outcome

The title should be above the axis labels

grafik

Additional information

  • This bug happens with the new 3.10 version, but with the 3.9.4 version
    I performed a git bisect using this:
 git bisect start
git bisect good v3.9.4
git bisect bad HEAD

a small test script check.py - there's probably a better way, but that's what I came up with. (Note that the issues also comes up when not using `bbox_inches='tight', but this way it was easier to bisect, since I could instrument the image size)

import matplotlib.pyplot as plt
from PIL import Image

def main():
    plt.polar([0, 1], [0, 1])
    plt.title('My Title')
    plt.savefig('output.png', bbox_inches='tight')
    with Image.open('output.png') as img:
        size = img.size

    if size != (453, 464):
        return 1
    else:
        return 0

if __name__ == '__main__':
    raise SystemExit(main())

finally,

git bisect run python3 check.py

After a few steps it yielded this suspicious commit: 8abe308 (cc @rcomer) which was merged in #28300

Operating system

Ubuntu 22.04

Matplotlib Version

3.10.0.dev1180+gc2d502d219

Matplotlib Backend

agg

Python version

3.13.1

Jupyter version

No response

Installation

git checkout

@timhoffm
Copy link
Member

timhoffm commented Dec 27, 2024

Without having tested in code, I suspect that prior to #28300, l.3006

if (ax.xaxis.get_ticks_position() in ['top', 'unknown']

the “unknown” has likely caught the polar tick.

That has been cut out by a visible check on all tick.label2, an assumption that is correct only for rectangular axes, where label2 corresponds to the top labels of the x axis.

@rcomer rcomer added status: confirmed bug Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. labels Dec 27, 2024
@rcomer rcomer added this to the v3.10.1 milestone Dec 27, 2024
@rcomer
Copy link
Member

rcomer commented Dec 27, 2024

Well I'm glad I left good notes because otherwise what I did would be a mystery to me 😅. From #26150 (comment) Past Me thought another good option would be to return an extra option from get_ticks_position. For the target case, neither top nor bottom ticks were visible due to axis sharing, so it seems sensible to me that get_ticks_position could return "neither" or "none" rather than "unknown" for that case.

Thanks @jkittner for the clear report and for doing the bisect.

@timhoffm
Copy link
Member

that get_ticks_position could return "neither" or "none" rather than "unknown" for that case.

Or “other”?

@rcomer
Copy link
Member

rcomer commented Dec 27, 2024

Why "other"? That seems no more specific than "unknown". For the sharex case we know that neither top nor bottom ticks are visible, so we can explicitly check for that case which is not currently considered by get_ticks_position.

@timhoffm
Copy link
Member

timhoffm commented Dec 27, 2024

Sorry, maybe out of context because I’m writing from a phone and may have overlooked something.
My thought was that polar ticks are nether “top” nor “bottom” not “unknown”, but in another arrangement.

@rcomer
Copy link
Member

rcomer commented Dec 27, 2024

Ah OK, we could do both "neither" for the sharex case and "other" for the polar case - though I'm not sure how best to detect the polar situation. In any case I propose to leave that question for v3.11 and just partially revert #28300 to fix the bug for v3.10.1 (see #29382).

aydinomer00 added a commit to aydinomer00/matplotlib that referenced this issue Dec 31, 2024
…itioning

- Add new public method get_title_top() to calculate title position
- Implement specialized versions for PolarAxes and GeoAxes
- Add tests for different projections
- Update _adjust_title_position to use the new method

This change allows subclasses to customize title positioning by
overriding get_title_top(), fixing the title position issue in
polar plots (matplotlib#29381).
aydinomer00 added a commit to aydinomer00/matplotlib that referenced this issue Dec 31, 2024
…itioning

- Add new public method get_title_top() to calculate title position
- Implement specialized versions for PolarAxes and GeoAxes
- Add tests for different projections
- Update _adjust_title_position to use the new method
- Improve documentation and code clarity

This change allows subclasses to customize title positioning by
overriding get_title_top(), fixing the title position issue in
polar plots (matplotlib#29381).
aydinomer00 added a commit to aydinomer00/matplotlib that referenced this issue Dec 31, 2024
- Fix code style issues
- Add test fixtures
- Improve documentation
- Clean up whitespace and formatting
- Fix test stub errors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Release critical For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions. status: confirmed bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants