Repository navigation
eps and useTex: tick labels drawn over legend box #131
Description
This is an issue originally reported in the mailing list by Brannon (giltirn@gmail.com).
http://old.nabble.com/eps-and-useTex%3A-tick-labels-drawn-over-legend-box-td31744864.html
Hi,
I am having trouble with matplotlib 1.0.1 drawing the axis tick labels over
the legend box in the eps output when useTex is set to true. The plot shown
after calling plt.show() looks fine, as does the output in pdf, png, svg
etc. Only the postscript appears to be affected.
The following simple example produces the png and eps files given at the
bottom of this post:
import matplotlib as mpl
import matplotlib.pyplot as plt
from matplotlib import rc
rc('text', usetex=True)
g1, = plt.plot([1,2,3,4],[500,600,700,800])
g2, = plt.plot([1,2,3,4],[700,300,700,200])
g3, = plt.plot([1,2,3,4],[800,600,900,800])
plt.figlegend([g1,g2,g3],['test1','test2','test3'],'upper left')
plt.savefig('image.png')
plt.savefig('image.eps')
plt.show()
http://old.nabble.com/file/p31744864/image.eps image.eps
http://old.nabble.com/file/p31744864/image.png image.png
I would very much appreciate some help resolving this issue.
Thanks
Activity
pelson commented on Jun 18, 2012
Confirmed on master (after v1.1.1rc2 has been released).
@mdboom: Do we have a ps backend maintainer?
dmcdougall commented on Aug 22, 2012
Confirmed on current master (currently at 42878d2) post 1.2 feature-freeze, too.
I've had a quick look at this. The PS backend does all the figure rendering first, and then processes the TeX. It's weird, since the tick label that's technically meant to be 'under' the legend box is classed returns True for get_visible(). This is also the case in the PDF backend, but I guess the PDF does the stacking in the backend properly, I don't know.
In any case, shouldn't get_visible() return False for the Text artist underneath the legend box?
WeatherGod commented on Aug 22, 2012
On Wed, Aug 22, 2012 at 12:57 PM, Damon McDougall
notifications@github.comwrote:
get_visible() has nothing to do with whether it is visible through all
layers, but rather whether it is ever drawn or not. It is impossible to
know if any other artist is being drawn on top of it or not (and what if
that object is partly transparent?)
So, it seems that the PS backend violates the zorder settings by deferring
the TeX elements to later. That would be the main bug that would have to
be addressed.
Ben Root
dmcdougall commented on Aug 22, 2012
Thanks for the clarification.
If that's the case, then this will be very invasive to fix. I'm a little confused as to why the latex wasn't just embedded on the fly. Perhaps this is a limitation of PostScript.
efiring commented on May 29, 2013
Checked with master prior to 1.3 release: the bug has not magically disappeared.
dmcdougall commented on Jun 23, 2013
@efiring I think to fix this would require some pretty major thinking and open heart surgery on the PS backend, unless someone can see an easier way. Once upon a time I did a quick comparison with the PDF backend to try and see if we could steal some of the latex zorder functionality and port it to the PS backend but I got lost pretty quickly.
efiring commented on May 22, 2016
@jkseppan, I suspect this bug is very hard to fix, and is not going to get fixed, in which case it would be nice to close it with a "won't fix". I presume a reasonable workaround is to use the pdf backend instead and then use convert or gs to generate the ps or eps file. Maybe a note to that effect could go in the docs.
jkseppan commented on May 22, 2016
Perhaps I can give some background on why the backend works this way. When you create EPS files in something like Matlab, you cannot usually typeset math inside the files. If you include a Matlab EPS file in your TeX document, the text and equations in it are going to look different from the rest of the document. That's why psfrag was created: you'd enter just some placeholder text in Matlab, and use the psfrag macros to generate some magic PostScript code to change the placeholders to equations rendered by TeX, and when this code is included in the output of dvips it would modify the included EPS file accordingly. Now the matplotlib PostScript backend adds one more layer by creating a LaTeX file that uses psfrag to modify the intermediate matplotlib output to render equations in TeX, and calling latex and dvips on it. I don't think there is any deep technical reason that z-order could not be made to work, but even figuring out which part of the Python/TeX/dvips/PostScript polyglot stack is doing it wrong is going to be a challenge. Certainly in the original use case of psfrag you'd want the equations to be typeset on top of any Matlab plots.
When I implemented usetex for the pdf backend, I couldn't do the same, since psfrag is implemented with PostScript tricks and depends on dvips. Thus we have dviread, which takes a different approach and has different bugs, so going via the pdf backend and using some pdf→ps converter can give different results.
dstansby commented on Dec 29, 2022
Just tried the code above and it seems fine to me now - I guess it was fixed at some point between 2016 and now, so going to close!