Skip to content

Colorbar outline has broken path in vector backends #4185

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
u55 opened this issue Mar 3, 2015 · 7 comments · Fixed by #4186
Closed

Colorbar outline has broken path in vector backends #4185

u55 opened this issue Mar 3, 2015 · 7 comments · Fixed by #4186
Assignees
Milestone

Comments

@u55
Copy link
Contributor

u55 commented Mar 3, 2015

Hi again,
In all of the vector graphics backends that I tested (pdf, eps, ps, svg), the colorbar outline is drawn with a broken path at the corner where the path starts and ends. This does not happen with the raster graphic or interactive backends. Here is a minimal working example:

import numpy as np
import matplotlib as mpl
import matplotlib.pyplot as plt

mpl.rcParams.update({'axes.linewidth':10})

fig = plt.figure(figsize=(8,6))
ax1 = fig.add_axes([0.05, 0.85, 0.9, 0.1])
ax2 = fig.add_axes([0.05, 0.65, 0.9, 0.1])
ax3 = fig.add_axes([0.05, 0.45, 0.9, 0.1])
ax4 = fig.add_axes([0.05, 0.25, 0.9, 0.1])
ax5 = fig.add_axes([0.05, 0.05, 0.9, 0.1])

cmap = mpl.cm.jet
cmap.set_under('w')
cmap.set_over('w')

im = ax1.pcolormesh(np.linspace(0,10,16).reshape((4,4)))

plt.colorbar(im,cax=ax2,cmap=cmap,orientation='horizontal',
             extend='both',extendfrac=0.5)
plt.colorbar(im,cax=ax3,cmap=cmap,orientation='horizontal',
             extend='both',)
plt.colorbar(im,cax=ax4,cmap=cmap,orientation='horizontal',
             extend='both',extendrect=True)
plt.colorbar(im,cax=ax5,cmap=cmap,orientation='horizontal',
             extend='neither')

plt.savefig('colorbar_tip.pdf')
plt.savefig('colorbar_tip.eps')
plt.savefig('colorbar_tip.svg')

Tested with matplotlib 1.4.3, and python 2.7, on Linux and Windows. I have exaggerated the axes linewidth to make the problem more visible. Here is a screenshot of the PDF output:

colorbar_tip

I have been able to fix this by making the following change to the ColorbarBase class in colorbar.py:

def _config_axes(self, X, Y):

    ...

    if self.outline is not None:
        self.outline.remove()

    xy2 = np.append(xy,xy[1:2,:],axis=0) # <-- added

    self.outline = mpatches.Polygon(
        xy2, edgecolor=mpl.rcParams['axes.edgecolor'], # <-- modified
        facecolor='none',
        linewidth=mpl.rcParams['axes.linewidth'],
        closed=True,
        zorder=2)

    ...

This essentially just copies the second point of the path to the end of the path. However, I don't know if this is the best fix. I don't know anything about vector graphics drawing directives, but it seems to me that there should be a builtin function to have paths wrap-around enough so that it creates a closed loop, including drawing the correct corner. Clearly the closed=True option of the mpatches.Polygon is not doing this.

Again, thanks to anyone who looks into this.

@efiring
Copy link
Member

efiring commented Mar 3, 2015

Confirmed on master. You are correct: the closed=True is supposed to be taking care of this, so we will have to figure out why it is not doing so. This seems familiar, as if we found and fixed this problem before...

@tacaswell tacaswell modified the milestones: Color overhaul, next point release Mar 3, 2015
@u55
Copy link
Contributor Author

u55 commented Mar 3, 2015

@efiring you are right, this was addressed by issue #2864, which was closed on March 4. Somehow the problem has returned.

@tacaswell
Copy link
Member

We fixed this on Axes objects. IIRC, colorbars use a Line2D or something similarly surprising to draw their boundary...

@mdboom mdboom self-assigned this Mar 3, 2015
@efiring
Copy link
Member

efiring commented Mar 3, 2015

Not so surprising: patches.Polygon, because the boundary can be 4, 5, or 6-sided. The problem is in how the vector backends are handling the closed path; agg is handling it correctly.

@u55
Copy link
Contributor Author

u55 commented Mar 3, 2015

The Axes problem was addressed in issue #2542 and fixed by PR #2544 .

@mdboom
Copy link
Member

mdboom commented Mar 3, 2015

Yeah -- it's something pretty fishy. Looking into it now.

@mdboom
Copy link
Member

mdboom commented Mar 3, 2015

Looks like this was broken last August by me: 40f201c

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants