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_minusdoesn’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 commentedon 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 acheck_figures_equaltest and apparently both methods draw an invisible minus sign, so the test passes even though it's broken. And there are other more complexusetextests that do check against a baseline, but they seem to not include a minus sign.ksunden commentedon Jun 19, 2026
Bisects to 76d8b3c from #20716
Regarding embedding of Type-1 Fonts in PDF files
QuLogic commentedon 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:
so the minus sign actually occupies both the 0 and 161 codes.
From here in that PR, we set 0 to
.notdefin 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
.notdefin 0, I'm not sure that's required, especially for type 1 fonts. Moving.notdeffromencodingthere totododoes fix the issue, but I need to do some testing to ensure that doesn't have unforeseen consequences.binado commentedon Jul 8, 2026
Hi, does this mean that this bug will be fixed in the 3.11.1 release? Thanks!
QuLogic commentedon Jul 8, 2026
Yes, it will be fixed in 3.11.1, which will be out soon.
marzapane commentedon 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 commentedon 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 commentedon 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