GeezerVison is showing github.com — [Bug]: Exponential numbers on axis look like 10Σ² instead of 10⁻² with backend_gtk3cairo · Issue #32084 · matplotlib/matplotlib
[Bug]: Exponential numbers on axis look like 10Σ² instead of 10⁻² with backend_gtk3cairo #32084DescriptionBug summary
I recently installed matplotlib 3.11.0 and logarithmic axes now look like this.
Code for reproduction
#... basically any values from 0 to 1 will do
ax.plot(x, y)
ax.set_yscale('log')
#...Actual outcome
Expected outcome
Axes used to print normal exponential numbers.
Additional information
No response
Operating system
Ubuntu
Matplotlib Version
3.11.0
Matplotlib Backend
No response
Python version
gtk3agg
Jupyter version
No response
Installation
pip Activityrcomer commented on Jul 21, 2026 Hi @FilipDominec thanks for the report. Please could you provide a complete code example we can run? rcomer commented on Jul 21, 2026 With our main development branch and
fig, ax = plt.subplots()
ax.plot([0.04, 0.07])
ax.set_yscale('log')
plt.savefig('test.png')I get
 FilipDominec commented on Jul 21, 2026 @rcomer , I got the wrong result above using a GUI frontend (https://github.com/FilipDominec/nihilnovi/), whereas typing out a minimum standalone working example like
#!/usr/bin/env python3
#-*- coding: utf-8 -*-
import matplotlib.pyplot as plt
fig, ax = plt.subplots()
x = [1., 2., 2.5, 2.75, 2.9, 3., 3.25, 4., ]
y = [40e-3, 40e-3, 41e-3, 44e-3, 60e-3, 70e-3, 60e-3, 44e-3]
ax.plot(x, y)
ax.set_yscale('log')
fig.savefig('out.png')gives correct axes, as you show above.
So I will dig into my codes to trace down what option I use there that triggers the new error. FilipDominec commented on Jul 21, 2026 In a short standalone script, I couldn't reproduce the error with the explicit matplotlib & backends configuration I am using in the graphical app.
But asking Claude to sketch a simple plotting GUI isolates the error (scripts attached).
b-cairo.py
b-tk.py
It seems to me there might be some recent change in the matplotlib.backends.backend_gtk3cairo. changed the title [-][Bug]: Exponential numbers on axis look like 10Σ² instead of 10⁻²[/-] [+][Bug]: Exponential numbers on axis look like 10Σ² instead of 10⁻² with backend_gtk3cairo[/+] on Jul 21, 2026QuLogic commented on Jul 21, 2026 Is there a reason you are using the Gtk3Cairo backend over the Gtk3Agg one? The Cairo backends tend to be less well tested and featureful. If you really want to use Cairo, it may be better to use mplcairo. QuLogic commented on Jul 22, 2026 The problem here is that both Pycairo and cairocffi only support the toy font face API in Cairo. The toy font face API only supports selecting a font with a family name (plus some modifiers) and no explicit path. In 3.11, we switched from sending characters directly to Cairo and instead using the glyphs selected by libraqm. This is slightly less of the toy API since Cairo doesn't expose any way to pick language/font features/alternate glyphs/etc if giving it characters only.
Unfortunately, we ship a copy of DejaVu Sans that isn't the same as the current system one:
>>> from fontTools.ttLib import TTFont
>>> ours = TTFont('lib/matplotlib/mpl-data/fonts/ttf/DejaVuSans.ttf')
>>> ours.getGlyphName(3228)
'minus'
>>> system = TTFont('/usr/share/fonts/dejavu-sans-fonts/DejaVuSans.ttf')
>>> system.getGlyphName(3228)
'summation'AFAICT, Cairo passes that family to fontconfig and doesn't parse it as a fontconfig pattern, so we can't even do a trick like pass :file=/path/to/DejaVuSans.ttf (and in any case, it would only accept explicit paths that are in the fontconfig system/user path not our arbitrary file.)
There are two possible fixes:
- Go back to character codes. Since that is the toy API, it probably means that alternate glyphs and font settings won't work properly.
- Manually load the other non-toy API in the same way as mplcairo does. This is a lot more work as we need to handle all the different ways that Cairo might be loaded.
QuLogic commented on Jul 22, 2026 Though now that I look at it closer, regular text doesn't go through libraqm for the Cairo backends; they just use show_text with the characters. So it is likely safe enough to revert mathtext to characters again, as it will work about the same as it used to (which is to say not perfectly, but likely good enough.)
That being said, since the Cairo backends don't support full internationalization and other advanced font features, I'd highly recommend switching to one of the Agg backends. FilipDominec commented on Jul 22, 2026 @QuLogic I could trace my decision of switching from Agg to Cairo to solving AttributeError: 'FigureCanvasTk' object has no attribute 'set_size_request' error few years ago. It seems this error got meanwhile addressed here. Or maybe AI will help me switch back to Agg once I get to full refactoring my application. I love the capabilities of Matplotlib, but I must say programming GUI with Matplotlib backends hasn't been an entirely smooth experience for me. added a commit that references this issue on Jul 23, 2026This issue will close once commit 42e0d6b is merged into the 'main' branch.42e0d6b
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
