cc @pwuertz Can you mile stone this appropriately?

Well, the path matplotlib provides for the second hatch pattern contains a whopping number of 6130 path segments. This naturally increases the number of pgf commands which latex cannot handle anymore at some point.

backend_svg suffers from the same problem, but backend_pdf doesn't seem to use the hatch path at all and simply interprets the hatch name. The naming scheme appears to be native to PDF, but I don't know much about this format.

So it looks like the pattern generated for all the non-PDF backends isn't very efficient when you shrink the elements / increase the pattern's density.

Well, actually its only the circular patterns that seem to be overly complicated. Even the basic patterns contain 500-1000 segments.

Does anybody know some details about how/where these patterns are created within matplotlib? Since cubic splines are supported in Path, a simple circle shouldn't require more than 4 path segments.

The hatches are generated in hatch.py, but many of them use lower-level paths from path.py.

Since the circle path is often used quite large in matplotlib, it actually uses an 8-cubic-spline approximation, not a 4-cubic-spline one, because the error was noticable on high-resolution plots, particularly if only part of the circle was shown. For hatching, that level of accuracy isn't necessary, of course, so added a 4-spline approximation for that purpose would be fine.

But that doesn't explain why we see 500-1000 segments. Perhaps a bezier spline to line segment conversion is happening somewhere along the way?

Ok, so for the "o" pattern I'm seeing circle instances using the 8 segment approximation you were mentioning. For each dot there are two circles, a smaller and a larger one. The basic hatch pattern contains about 50 dots, which amounts to 800 segments. So the problem isn't really the number of segments per circle, it's the amount of circles.

I see -- in that case, the solution may be to reduce the size of the hatch pattern so it contains fewer circles. Unfortunately, it's currently hard-coded, i.e. all of the backends assume the hatch pattern is a 1x1inch square. So I think fixing that will require updating all of the backends.

Thank you for the fast responses and good luck with fixing this. I wasn't aware that it was such a general issue.

Oh, I am mistaken. Also the PDF backend uses the hatch path from matplotlib, it just uses a different method for retrieving it. However, at least on my system the hatch pattern appears to be rasterized in the PDF output, which explains the much smaller file size compared to the fully vectorized PGF or PGF->PDF output.

Scaling of the pattern density within the backend sounds like a good approach. But yes, every backend would need to implement this individually, which probably won't happen anytime soon. I don't see a good workaround, other than to avoid using non-trivial high-density patterns for now.

Thanks for the quick reply @mdboom

I am not sure, but doesn't this #4108 indicate that the PDF backend does not render the hatch pattern?

@jowr You are right, on my Ubuntu system it was the default PDF viewer that rasterized the hatch pattern before applying it, the document is fully vectorized. So it's just PDF being able to store the pattern more efficiently than a million lines of latex code ;)

Interesting... PDF is zlib compressing the path data, so that's probably a lot better than PGF wrt file size. SVG is also pretty bad, but still about half the size of PGF. PGF is just really verbose unfortunately, and probably really works the TeX parser, whereas SVG and PDF both have much simpler languages to represent paths.

This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!