Skip to content

Conversation

@SimonHeybrock
Copy link
Member

@SimonHeybrock SimonHeybrock commented Nov 3, 2025

I don't know if there is a simpler way of reproducing this outside a notebook?

@nvaytet You probably have a better way to fix this, please feel free to ignore or push to this branch instead!

SimonHeybrock and others added 3 commits November 3, 2025 08:35
Test that calling tight_layout() on a figure with logc=True does not raise
a ValueError from matplotlib's mathtext parser. This test currently fails
with the error from error_message.txt where LogNorm tick labels like
"$\mathdefault{10^{-33}}$" cause parsing errors during layout calculations.

Original task: A user is reporting that plotting a 2D data array with coords on logc (data range ~[0,800]) results in @error_message.txt - can you investigate?

🤖 Generated with Claude Code

Co-Authored-By: Claude <[email protected]>
When plotting 2D data with logc=True and calling tight_layout(), matplotlib's
default LogNorm formatter generates tick labels with mathtext notation like
"$\mathdefault{10^{-33}}$". During tight_layout() text extent calculations,
matplotlib re-parses these labels and encounters parsing errors due to nested
dollar sign delimiters.

Solution: Set a custom FuncFormatter for logc colorbars that generates plain
text labels (e.g., "1e+02") instead of mathtext notation. This formatter is:
- Applied when the colorbar is created
- Re-applied after normalizer limits change (in apply_limits)
- Re-applied when toggling between linear and log scales

This prevents the mathtext parsing errors while maintaining readable tick labels.

Fixes issue where .plot(logc=True).to_widget() raises ValueError on data ranges
like [0, 800].

Resolves: test_logc_tight_layout_does_not_raise_parse_error

Original task: A user is reporting that plotting a 2D data array with coords on logc (data range ~[0,800]) results in @error_message.txt - can you investigate?

🤖 Generated with Claude Code

Co-Authored-By: Claude <[email protected]>
@SimonHeybrock SimonHeybrock marked this pull request as draft November 3, 2025 08:41
@nvaytet
Copy link
Member

nvaytet commented Nov 3, 2025

I don't think we should try to fix this, I suspect it's a matplotlib issue...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants