Repository navigation
Closed
Labels
Release criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.backend: pgf
Milestone
Description
Bug report
Bug summary
When using matplotlib 3.2, the PGF backend and the rcParam "savefig.bbox" set to "tight", plt.savefig error with ValueError: I/O operation on closed file. Works fine on 3.1.3.
Code for reproduction
import matplotlib as mpl
mpl.use("pgf")
import matplotlib.pyplot as plt
plt.rcParams.update({"pgf.texsystem": "lualatex", "savefig.bbox": "tight"})
fig, ax = plt.subplots()
ax.plot([1.0, 2.0, 3.0], [4.0, 5.0, 6.0])
plt.savefig("test.pdf")I don't know if the lualatex is necessary to reproduce, I just didn't have xelatex installed. Without the savefig.bbox it works fine.
Actual outcome
Traceback (most recent call last):
File "test.py", line 9, in <module>
plt.savefig("test.pdf")
File "/usr/local/lib/python3.7/dist-packages/matplotlib/pyplot.py", line 723, in savefig
res = fig.savefig(*args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/matplotlib/figure.py", line 2203, in savefig
self.canvas.print_figure(fname, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/matplotlib/backend_bases.py", line 2067, in print_figure
self.figure.draw(renderer)
File "/usr/local/lib/python3.7/dist-packages/matplotlib/artist.py", line 38, in draw_wrapper
return draw(artist, renderer, *args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/matplotlib/figure.py", line 1734, in draw
self.patch.draw(renderer)
File "/usr/local/lib/python3.7/dist-packages/matplotlib/artist.py", line 38, in draw_wrapper
return draw(artist, renderer, *args, **kwargs)
File "/usr/local/lib/python3.7/dist-packages/matplotlib/patches.py", line 602, in draw
self._facecolor if self._facecolor[3] else None)
File "/usr/local/lib/python3.7/dist-packages/matplotlib/backends/backend_pgf.py", line 476, in draw_path
writeln(self.fh, r"\begin{pgfscope}")
File "/usr/local/lib/python3.7/dist-packages/matplotlib/backends/backend_pgf.py", line 118, in writeln
fh.write(line)
ValueError: I/O operation on closed file.
Expected outcome
Works in 3.1.3.
Matplotlib version
- Operating system: Debian Stable
- Matplotlib version: 3.2
- Matplotlib backend (
print(matplotlib.get_backend())): pgf - Python version: 3.7
Installed matplotlib from pip.
Reacted by h4nek
Metadata
Metadata
Assignees
Labels
Release criticalFor bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.For bugs that make the library unusable (segfaults, incorrect plots, etc) and major regressions.backend: pgf
Activity
tacaswell commentedon Mar 11, 2020
@Psirus I don't have pgf set up on the machine I am currently on, can you confirm it works without the tight bounding box?
Psirus commentedon Mar 11, 2020
Yes, if I remove the
savefig.bboxor set it tostandard, it works.tacaswell commentedon Mar 11, 2020
attn @anntzer I suspect this is related to the cleanup to the pgf code.
I suspect the problem is that to do the 'tight' bounding box we have to render the figure twice but are not getting a fresh file handle the second time.
PanagiotisS commentedon Mar 11, 2020
Hi,
I have same (?) issue when using pgf backend, savefig with bbox, and matplotlib version 3.2.
Matplotlib version 3.1.3 works without problem. or matplotlib version 3.2, pgf, without bbox.
Same problem appears with python 3.6.9 when installing matplotlib through pip or with python 3.8.1 through conda env.
I created a new conda env where only matplotlib was installed in order to test it.
I hope this can be of use to you
anntzer commentedon Mar 11, 2020
I understand where the problem comes from, but it's going to be slightly tricky to fix so it will likely take a few days.
Basically this comes from the fact that the pgf backend needs to interact for real with the filesystem even when saving to an in-memory BytesIO() object (both because of TeX, and because draw_image works by saving to an image and then includegraphics'ing it). This breaks the assumption I made in #14134, which is that the "dummy" renderer used for tight-layouting could just use an in-memory buffer without filesystem considerations.
tacaswell commentedon Mar 11, 2020
Is the fastest path to revert #14134 for 3.2.x or is there a bunch of follow on PRs that would also need to be backed out?
anntzer commentedon Mar 11, 2020
Reverting #14134 and its followup #14216 is likely easiest for 3.2.
edit: now done as #16732.