Confirmed on master (after v1.1.1rc2 has been released).

@mdboom: Do we have a ps backend maintainer?

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?

On Wed, Aug 22, 2012 at 12:57 PM, Damon McDougall
notifications@github.comwrote:

Confirmed on current master (currently at 42878d242878d2)
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?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/131#issuecomment-7941132.

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

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.

Checked with master prior to 1.3 release: the bug has not magically disappeared.

@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.

@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.

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.

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!