You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Interactive save should respect 'savefig.facecolor' rcParam. #3437
Currently, there is no way to set the figure facecolor when saving a figure interactively via the NavigationToolbar2 graphical save button. All interactive backends, that I have tested, default to a white facecolor while ignoring the 'savefig.facecolor' rcParam. I propose to change this behavior such that every backend will respect the 'savefig.facecolor' rcParam.
One possible option would be to edit the save_figure method of each backend-specific class which inherits from matplotlib.backend_bases.NavigationToolbar2 in every backend. This seems tedious.
Another option would be to edit the print_figure method in matplotlib.backend_bases.FigureCanvasBase, which every backend inherits from. This seems simpler.
For instance, adding the following indicated lines to matplotlib.backend_bases.FigureCanvasBase.print_figure works for me.
Good point; I agree, the rcParams should be respected. I wonder, though, whether what is really needed is a little refactoring. It looks like the correct logic is in Figure.savefig, which also handles the savefig.transparent option. Why do we need both Figure.savefig and backend_bases.print_figure with such similar signatures and docstrings? It is hard to follow the trail of what gets called when a figure is saved; and it seems like saving a figure via the Toolbar should be able to take advantage of the same code that is invoked by explicitly calling Figure.savefig.
I'm not sure if your question was directed at me or other developers. The matplotlib.figure.Figure.savefig method ends up calling the backend's print_figure method via the call:
self.canvas.print_figure(*args, **kwargs)
So the logic which implements the rcParams could be moved from matplotlib.figure.Figure.savefig to matplotlib.backend_bases.FigureCanvasBase.print_figure. But this will only work if each and every interactive and non-interactive backend uses the matplotlib.backend_bases.FigureCanvasBase.print_figure method that it inherits instead of implementing its own print_figure method. I'm not sure if this is a safe thing to depend on.
Has anyone found a workaround for this in the meantime? No matter what I try, my interactive plots are saving with a white background which makes all of the labels completely unreadable. Do I have to waste time redesigning my color scheme or can someone point me in the right direction.
@braxtonj, I believe that the only two workarounds are: (1) save the figure programmatically via the savefig method rather than saving interactively, or (2) modify the source code to the file matplotlib.backend_bases.FigureCanvasBase.print_figure as suggested in my first post.
I know there's a major update to mpl in the works (heard about it in various pycon/scipy talks).
Will this issue be addressed in the next edition of mpl?
For GUI programs that are already using the built in mpl toolbar it would be nice to have the savefig button on the toolbar respect rcParams rather than having to manually add another GUI element to place a call programmatically to savefig() for the sole purpose of changing the facecolor of the saved image and thus essentially having a dead item in the built in toolbar ...
Activity
efiring commentedon Aug 30, 2014
Good point; I agree, the rcParams should be respected. I wonder, though, whether what is really needed is a little refactoring. It looks like the correct logic is in Figure.savefig, which also handles the savefig.transparent option. Why do we need both Figure.savefig and backend_bases.print_figure with such similar signatures and docstrings? It is hard to follow the trail of what gets called when a figure is saved; and it seems like saving a figure via the Toolbar should be able to take advantage of the same code that is invoked by explicitly calling Figure.savefig.
u55 commentedon Aug 31, 2014
Hi Eric,
I'm not sure if your question was directed at me or other developers. The
matplotlib.figure.Figure.savefigmethod ends up calling the backend'sprint_figuremethod via the call:So the logic which implements the rcParams could be moved from
matplotlib.figure.Figure.savefigtomatplotlib.backend_bases.FigureCanvasBase.print_figure. But this will only work if each and every interactive and non-interactive backend uses thematplotlib.backend_bases.FigureCanvasBase.print_figuremethod that it inherits instead of implementing its ownprint_figuremethod. I'm not sure if this is a safe thing to depend on.braxtonj commentedon May 21, 2015
Has anyone found a workaround for this in the meantime? No matter what I try, my interactive plots are saving with a white background which makes all of the labels completely unreadable. Do I have to waste time redesigning my color scheme or can someone point me in the right direction.
This is what I have thusfar:
The dpi works just find but not the savefig.facecolor nor savefig.edgecolor
Thanks,
Braxton
u55 commentedon May 23, 2015
@braxtonj, I believe that the only two workarounds are: (1) save the figure programmatically via the
savefigmethod rather than saving interactively, or (2) modify the source code to the filematplotlib.backend_bases.FigureCanvasBase.print_figureas suggested in my first post.tacaswell commentedon May 23, 2015
@u55 Can you put in a PR with that change?
mgrady3 commentedon Aug 3, 2015
Has any further work been done on this PR?
I know there's a major update to mpl in the works (heard about it in various pycon/scipy talks).
Will this issue be addressed in the next edition of mpl?
For GUI programs that are already using the built in mpl toolbar it would be nice to have the savefig button on the toolbar respect rcParams rather than having to manually add another GUI element to place a call programmatically to savefig() for the sole purpose of changing the facecolor of the saved image and thus essentially having a dead item in the built in toolbar ...
tacaswell commentedon Aug 30, 2015
ping @u55
tacaswell commentedon Mar 28, 2016
closed by #6197