Repository navigation
[Bug]: minus signs not rendered in PDF export with TeX #31925
Description
Bug summary
When I use TeX to render, minus signs do not appear in exported PDFs anymore.
- They show fine in Jupyter and exported PNGs or SVGs.
- Other mathematical symbols are unaffected (also see the example). So far, I only found minus signs to be affected.
- Activating axes.unicode_minus doesn’t help.
- If I downgrade Matplotlib to 3.10.9 (and leave everything the same), the minuses are rendered. I therefore would exclude a straightforward problem with my TeX installation etc. Perhaps, this is related to Rasterize dvi files without dvipng. #30039.
Code for reproduction
from matplotlib.pyplot import subplots
from matplotlib import rcParams
rcParams["text.usetex"] = True
# rcParams["axes.unicode_minus"] = False
fig,axes = subplots(figsize=(3,2))
axes.plot([-1, 1], [-1, 1])
axes.text(-0.5,0.5,r"$\sum_{\alpha=-1}^{\Psi} \pm \pi$")
fig.savefig("test.pdf")Actual outcome
Expected outcome
Operating system
Arch
Matplotlib Version
3.11.0
Matplotlib Backend
qtagg
Python version
3.14.5
Installation
Linux package manager
Activity
QuLogic commented on Jun 19, 2026
So we do have a test that covers a minus sign (with Unicode minus enabled) in lib/matplotlib/tests/test_usetex.py::test_unicode_minus, but it's a check_figures_equal test and apparently both methods draw an invisible minus sign, so the test passes even though it's broken. And there are other more complex usetex tests that do check against a baseline, but they seem to not include a minus sign.
ksunden commented on Jun 19, 2026
Bisects to 76d8b3c from #20716
Regarding embedding of Type-1 Fonts in PDF files
QuLogic commented on Jun 19, 2026
We spent some time looking at this earlier. Computer Modern and all the older LaTeX fonts are known to use a pretty weird encoding. Looking at the PDF results before that change, it has:
0 1 255 { 1 index exch /.notdef put} for dup 0 /minus put ... dup 161 /minus putso the minus sign actually occupies both the 0 and 161 codes.
From here in that PR, we set 0 to .notdef in the subset encoding. LaTeX picks 0 (not 161) for the minus sign, and since we've replaced it in this encoding, we subset the font into nothing.
While it is recommended that fonts put .notdef in 0, I'm not sure that's required, especially for type 1 fonts. Moving .notdef from encoding there to todo does fix the issue, but I need to do some testing to ensure that doesn't have unforeseen consequences.
binado commented on Jul 8, 2026
Hi, does this mean that this bug will be fixed in the 3.11.1 release? Thanks!
QuLogic commented on Jul 8, 2026
Yes, it will be fixed in 3.11.1, which will be out soon.
marzapane commented on Jul 17, 2026
What would you suggested for those who need the issue fixed before version 3.11.1 is eventually published?
By the way, thanks a lot to all you developers behind this invaluable tool, I use it everyday with great satisfaction!
Wrzlprmft commented on Jul 17, 2026
As I mentioned in the initial report, it works in Version 3.10.9. So unless you need a more recent feature or fix, downgrade to that version.
QuLogic commented on Jul 18, 2026
I just released 3.11.1, so you can update to that also.
bump mpl version to include fix for minus issue