Fix y-label overlap with tick labels for non-default rotations#31463
Open
FazeelUsmani wants to merge 2 commits intomatplotlib:mainfrom
Open
Fix y-label overlap with tick labels for non-default rotations#31463FazeelUsmani wants to merge 2 commits intomatplotlib:mainfrom
FazeelUsmani wants to merge 2 commits intomatplotlib:mainfrom
Conversation
…otlib#19029) `YAxis._update_label_position` previously assumed a 90° label rotation when computing the label's position, so y-labels with other rotations (e.g. ``rotation=270`` for right-side colorbar labels) could overlap the tick labels. The label position is now computed from the rendered label's actual extent, so it sits clear of the tick labels for any rotation. This implements @jklymak's suggestion in the issue thread of checking the rendered label extent against the tick labels in `_update_label_position`. The fix is a no-op for the default ``rotation=90`` case, so existing image baselines are unaffected. Tests added in test_axes.py cover the generic axis-layer fix (parametrized over 7 rotations × 2 label_positions) plus an ``align_ylabels`` regression that guards against the per-axis overhang correction breaking sibling alignment when rotations differ. A colorbar smoke test in test_colorbar.py exercises the original user-facing symptom from the issue via ``cbar.set_label(..., rotation=270)``.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #19029.
YAxis._update_label_positionwas setting the label position assuming a 90° rotation, so a y-label withrotation=270(most often hit viacbar.set_label(..., rotation=270)) ended up overlapping the tick labels. @timhoffm and @jklymak diagnosed this in the issue thread; this PR follows their suggested approach: in_update_label_position, after computing the tentative position, check the rendered label's actual extent and shift it outward by however much it overhangs into the tick label area. Rotation-agnostic.The fix is a no-op for
rotation=90, so existing image baselines are unaffected — @jklymak's "this will change many image tests" worry didn't pan out.Tests
test_ylabel_no_overlap_with_ticklabelsin test_axes.py — generic axis-layer regression, parametrized over 7 rotations × 2 label positionstest_align_ylabels_mixed_rotationin test_axes.py — guards against the per-axis overhang correction breakingfig.align_ylabels()when sibling axes use different rotations (the visible bboxes still match, even though the internal anchor positions differ)test_colorbar_label_rotation_no_overlapin test_colorbar.py — smoke test for the literal repro from the issue, viacbar.set_label('...', rotation=270)Local result: 1217 passed, 86 skipped across test_axes, test_axis, test_colorbar, test_subplots, test_constrainedlayout, test_tightlayout, test_figure. No image baseline regressions.