Among the arguments accepted by the fill function are color, edgecolor, facecolor, hatch, and alpha, and it's not obvious to me what the semantics should be, although it is clearly a bug that the agg and pdf backends create different output.

My guess is that the agg backend fills the area with "color", then draws hatches with "color", and applies alpha compositing to the two operations separately so that the hatches show up as a darker shade of blue. The pdf backend creates a tiling pattern that includes both the hatch lines and the fill color and paints the area with that pattern, with alpha set to 0.5. The effect is a uniform blue color, since the pattern is just full of blue, and compositing it on the canvas just makes it lighter. The workaround works because there are two separate objects being drawn, so they are composited on top of each other.

Should the pdf backend emulate the agg backend by drawing the hatch lines separately? Any other ideas?

Relatedly, is the same "alpha" supposed to apply to both facecolor and edgecolor? What should happen if one of these is an RGBA tuple?

What is the status of this issue?

Perhaps related, the contourf_hatching.py demo throws an exception when saving to PDF.

Perhaps related, the contourf_hatching.py demo throws an exception when saving to PDF.

I think that was a redherring which we managed to solve in #891.

None the less, the example given in this issue now produces a pdf on master which, when viewed in evince, has the desired hatch pattern.

@skovhus: Did you come across this issue because you are seeing the same problem?

I have just checked, and this is definitely fixed in v1.1.x branch (and hence 1.1.1rc2), although the hatching is made a little uglier by not having the hatch gap fix from #853 backported.

Yeah -- unfortunately #853 also required changing the hatch spacing, so it's a fairly visible change and in my mind went beyond a bug fix -- but it's certainly in a grey area in that regard.

This is a "feature" of MAC OSX which is called "anti-aliasing".
I've encountered the same problem recently (with recent version of mpl), the hatches are actually quite thin, and the MAC OSX PDF anti-aliasing filters just smooth them to vanish.

Opening the same figure with Xpdf just works fine ;)

It would be helpful to have some control on hatches thickness (mpl.rcParams[] seems to be ignored for hatches within a contourplot).

@dirteat, could you open a new issue describing this problem in more detail? The original bug here is different, and we don't want to confuse the two (similar) problems.