I can reproduce with 1.5.1rc1

By opening the file in inkscape I can see that the issue is the bbox of the colorbar. It extends well beyond the colorbar it self and is plotted on top of the image to the right.

I think this is a bug in the rasterising code revealed by #4481

If I disable the rasterization it looks right:

import matplotlib.pyplot as plt
import numpy as np

data = np.random.rand(100,100)

fig, ax = plt.subplots(1,2)
p1 = ax[0].pcolormesh(data)
p2 = ax[1].pcolormesh(data)

cb = plt.colorbar(p1,ax=ax[0])
plt.colorbar(p2,ax=ax[1])

cb.solids.set_rasterized(False)
fig.tight_layout()
fig.canvas
fig.savefig('test.pdf')
fig.savefig('test.eps')

This comes from the fact that the Postscript file format doesn't support alpha blending. So when you have an image with transparent pixels, they come out as white.

I suppose the best thing to do here is to turn off the colorbar rasterization when using the Postscript backend... I'll try to work up a PR shortly.

but, why is the bounding box for the colorbar not constrained?

On Fri, Jan 8, 2016 at 12:25 PM, Michael Droettboom <
notifications@github.com> wrote:

This comes from the fact that the Postscript file format doesn't support
alpha blending. So when you have an image with transparent pixels, they
come out as white.

I suppose the best thing to do here is to turn off the colorbar
rasterization when using the Postscript backend... I'll try to work up a PR
shortly.

—
Reply to this email directly or view it on GitHub
#5814 (comment)
.

This is going to be tricky to fix. The code that turns on rasterizing of colorbars is ignorant of the backend in use (and probably should remain so). The Postscript backend should probably be fixed so that when the rasterized layer contains alpha it falls back to not rasterizing. But I don't think it can figure that out before it actually rasterizes, so then it would have to store and play back the backend calls...

I'd really like to deprecate the Postscript backend -- there are fewer and fewer cases where Postscript is required but PDF can't be used instead. But I know there still a few tools and workflows that need Postscript, so that's probably not realistic yet.

but, why is the bounding box for the colorbar not constrained?

I think the code that "minimizes" the image is somehow broken...

How about we focus on fixing that first to minimize the impact this bug has?

On Fri, Jan 8, 2016 at 12:35 PM, Michael Droettboom <
notifications@github.com> wrote:

but, why is the bounding box for the colorbar not constrained?

I think the code that "minimizes" the image is somehow broken...

—
Reply to this email directly or view it on GitHub
#5814 (comment)
.

I winder if this problem exists also for pcolormesh plots, or if it is
specific to colorbar objects?

On Fri, Jan 8, 2016 at 12:41 PM, Benjamin Root ben.v.root@gmail.com wrote:

How about we focus on fixing that first to minimize the impact this bug
has?

On Fri, Jan 8, 2016 at 12:35 PM, Michael Droettboom <
notifications@github.com> wrote:

but, why is the bounding box for the colorbar not constrained?

I think the code that "minimizes" the image is somehow broken...

—
Reply to this email directly or view it on GitHub
#5814 (comment)
.

It's for anything that's rasterized (in this particular case, just the colorbars). I have a fix that I'll post shortly.