Just to be sure: the hatches do actually exist in the EPS file (e.g. the issue is only with the preview)? I ran your MWE on Linux and Python 2 with Matplotlib 1.5.1 and 2.0: in Evince I can see hatches in both of them. However the hatches do not look exactly identical between both records, which I guess is due to #7421 (ping @QuLogic)

@afvincent - yes, I think they do, I can see the hatches if I open the file with ghostscript

what is the diff between the two files?

The changes in the individual commits of #7421 are fairly self-contained; it should be possible to try reverting them one at a time to see if they have any effect. At a guess, I'd say this commit and Preview has some trouble with the setpattern shortcut. You can revert the very last block in that patch to test out that theory.

https://github.com/matplotlib/matplotlib/pull/7421/files#diff-b465967f537465fec4960b152fa49cffR903 is likely the specific change at fault.

https://www.adobe.com/products/postscript/pdfs/PLRM.pdf has the documentation on this and

setpattern is the normal method for selecting patterns; in practice, it is rarely necessary to set the color space and color value separately

pg 264

Sorry, unexpected workload at day-job last night. So here are the differences that I can observe both in Evince and GS between Matplotlib 1.5.1 and 2.0:

The main one is that the hatches do not have a constant line width with 2.0.

@WeatherGod I think the problem is not about the hatching style but more about how hatching is defined when saving in postscript and how it affects the rendering in Preview, Evince, GS, etc. as @QuLogic and @tacaswell have suggested. For example, when the hatches density is doubled ('//' instead of '/'), the not very aesthetic bold segments on some of the hatches are still there in EPS produced by 2.0, while the line width stays smooth and constant with 1.5(.1):

When I said diff I meant the text diff. I don't think the hatch changing width is real, that looks like issues with the renderer. Do they move around if you pan / zoom / resize the window?

The answer seems to be no with 1.5.1 (left panels) and yes with 2.0 (right panels):

The three level of zoom are 0.707, 1.000 and 2.000. With the EPS generated by Matplotlib 2.0, one can observe “glitches” for the two levels of zoom that are different from 1.

I agree that is is likely to be an issue with how the GS/Evince/Preview do the rendering.

I put the EPS files and a diff there

Hi, I've got a similar problem. I generate a hatched part in a figure with fill_between. Figure is saved to eps. It shows in Linux Document viewer and Okular.
If I now incorparate the file into a pdf document via latex, the hatching is only visible in ocular, not in the document viewer. Also not printed.

first picture: The file opened in document viewer individually as eps (left) and in the pdf (right). Hatching not in the pdf

second picture: The file opened in okular individually as eps (left) and in the pdf (right). Hatching visible

Punting to 3.0, this is not going to get fixed in the next few days.

I suspect that the resolution here is going to involve someone fully understanding the eps/pdf spec and then sorting out which of the viewers is buggy....

This reminds me of the clipping issues we hand with librsvg for a while (we were outputting svg that complied with the spec, but rsvg did not render them correctly).

Guys, has this issue been resolved? It seems like I'm having this problem on the latest module version. Or maybe any workaround?

@mryodo, I got the behaviour correct by inserting gsave and grestore in backend_ps.py. I don't known whether this will incur other problems, but at least you could give it a try.

I don't know how to present my modification here, so I just attach my git diff below. Hope it helps.

diff --git a/lib/matplotlib/backends/backend_ps.py b/lib/matplotlib/backends/backend_ps.py
index 62edbb919..c8877e2ab 100644
--- a/lib/matplotlib/backends/backend_ps.py
+++ b/lib/matplotlib/backends/backend_ps.py
@@ -311,7 +311,9 @@ class RendererPS(RendererBase):
             self._convert_path(Path.hatch(hatch), Affine2D().scale(sidelen),
                                simplify=False))
         self._pswriter.write("""\
+        gsave
         fill
+        grestore
         stroke
      } bind
    >>

https://stackoverflow.com/questions/6614207/how-to-export-non-blurry-eps-images for another case of Preview apparently not rendering postscript correctly.

@mksegv Thanx! Works perfectly!

@mryodo, I got the behaviour correct by inserting gsave and grestore in backend_ps.py. I don't known whether this will incur other problems, but at least you could give it a try.

I don't know how to present my modification here, so I just attach my git diff below. Hope it helps.

diff --git a/lib/matplotlib/backends/backend_ps.py b/lib/matplotlib/backends/backend_ps.py
index 62edbb919..c8877e2ab 100644
--- a/lib/matplotlib/backends/backend_ps.py
+++ b/lib/matplotlib/backends/backend_ps.py
@@ -311,7 +311,9 @@ class RendererPS(RendererBase):
             self._convert_path(Path.hatch(hatch), Affine2D().scale(sidelen),
                                simplify=False))
         self._pswriter.write("""\
+        gsave
         fill
+        grestore
         stroke
      } bind
    >>

Issue is still present in Matplotlib 3.1.1, but the posted fix worked like a charm! Thanks.

@mryodo, I got the behaviour correct by inserting gsave and grestore in backend_ps.py. I don't known whether this will incur other problems, but at least you could give it a try.

I don't know how to present my modification here, so I just attach my git diff below. Hope it helps.

diff --git a/lib/matplotlib/backends/backend_ps.py b/lib/matplotlib/backends/backend_ps.py
index 62edbb919..c8877e2ab 100644
--- a/lib/matplotlib/backends/backend_ps.py
+++ b/lib/matplotlib/backends/backend_ps.py
@@ -311,7 +311,9 @@ class RendererPS(RendererBase):
             self._convert_path(Path.hatch(hatch), Affine2D().scale(sidelen),
                                simplify=False))
         self._pswriter.write("""\
+        gsave
         fill
+        grestore
         stroke
      } bind
    >>

Does anyone want to open a PR for that change?

This should have been fixed by #15064.