BUG: align custom x tick label baselines - #32423

I pushed commit 3d7365a040 to address the remaining cross-platform image failures.

The first CI run showed that set_ticklabels() internally uses a FuncFormatter, so it was incorrectly included in the new custom-formatter baseline path. This commit marks that internal formatter as fixed-label formatting and leaves its existing layout unchanged. The affected set_get_ticklabels, colorbar, subfigure, and 3D image tests pass locally against the upstream baselines; the regression test for the reported custom formatter still passes.

The free-threaded Linux job had 3 image failures (all baseline/layout comparisons, no Python exceptions). A new CI run is now queued for the narrowed change.

Thanks for the detailed questions.

The regression is caused by the change in Text._get_layout() introduced by
97f4943cf279c82a4dc64e40ec52dcb1bcd218fe, which changed how font ascent and
descent are obtained. For top-aligned, single-line labels, strings with
different ascenders, such as "pol." and "1", can consequently receive
different line-box heights and appear with misaligned baselines. I confirmed
that this is the commit identified by the bisect in issue #32316.

The fix is limited to FuncFormatter because it can generate arbitrary text
for each tick and is the direct reproduction case. Fixed labels created by
set_ticklabels() are explicitly excluded, and the existing behavior of
numeric formatters and rotated labels is preserved.

_is_ticklabel limits the layout adjustment to tick-label text objects rather
than all Text instances. _is_custom_ticklabel_formatter distinguishes
user-provided formatters from the internal formatter used by
set_ticklabels().

I agree that dynamic private attributes are not ideal as a long-term design.
They were intended to keep this fix narrowly scoped without changing the
public API, and I am happy to refactor this part if a different internal
mechanism is preferred.

Thanks for the reply. Maybe I'm misunderstanding, but I have the impression that this is rather an operational fix for the given example but not a systematic identification and fix of the root cause.

For example, the issue example uses a FuncFormatter

gca().xaxis.set_major_formatter(lambda x, i: "pol." if x == 0 else str(int(x)))

I would expect - but have not checked yet - that a fixed formatter should render identically

gca().set_xticks([0, 1], labels=['pol.', str(1)])

If that's the case, a specific fix for FuncFormatter is not the way to go. If my assuption is wrong, I'd like to understand why FuncFormatter rendering is different than FixedFormatter rendering.