Repository navigation
Circular hatching patterns contain too many path segments #4122
Description
The produced PGF documents litarally explode in file size as soon as you start using dotted hatching patterns. Some of my graphs cannot be compiled by pdflatex anymore...
A simple plot like this one:
import matplotlib.pyplot as plt
fig = plt.gcf()
ax = fig.add_subplot(111)
ax.bar(0.85, 5, 0.3, color="lightgrey", hatch="////")
ax.set_xlim([0,3])
ax.set_ylim([0,10])
plt.tight_layout()
fig.savefig("pgfhatch_1.pgf")
fig.savefig("pgfhatch_1.pdf")
ax.bar(1.85, 7, 0.3, color="lightgrey", hatch="....")
fig.savefig("pgfhatch_2.pgf")
fig.savefig("pgfhatch_2.pdf")
plt.close()
produces files of very different sizes
-rw-r--r-- 1 jorrit jorrit 6.9K Feb 18 09:29 pgfhatch_1.pdf
-rw-r--r-- 1 jorrit jorrit 27K Feb 18 09:29 pgfhatch_1.pgf
-rw-r--r-- 1 jorrit jorrit 55K Feb 18 09:30 pgfhatch_2.pdf
-rw-r--r-- 1 jorrit jorrit 668K Feb 18 09:29 pgfhatch_2.pgf
However, the result is OK, but it takes ages to compile with pdflatex (if it succeeds).
\documentclass{standalone}
\usepackage{tikz}
\begin{document}
\begin{tabular}{cc}
\input{pgfhatch_1.pgf} & \input{pgfhatch_2.pgf} \\
\includegraphics{pgfhatch_1.pdf} & \includegraphics{pgfhatch_2.pdf}
\end{tabular}
\end{document}
Could it help to make real dots instead of circles?
Activity
tacaswell commentedon Feb 18, 2015
cc @pwuertz Can you mile stone this appropriately?
pwuertz commentedon Feb 18, 2015
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_svgsuffers from the same problem, butbackend_pdfdoesn'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.
pwuertz commentedon Feb 18, 2015
Well, actually its only the circular patterns that seem to be overly complicated. Even the basic patterns contain 500-1000 segments.
[-]PGF backend produces huge files for dotted hatching pattern[/-][+]Circular hatching patterns contain too many path segments[/+]pwuertz commentedon Feb 18, 2015
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.mdboom commentedon Feb 18, 2015
The hatches are generated in
hatch.py, but many of them use lower-level paths frompath.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?
pwuertz commentedon Feb 18, 2015
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.
mdboom commentedon Feb 18, 2015
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.
jowr commentedon Feb 18, 2015
Thank you for the fast responses and good luck with fixing this. I wasn't aware that it was such a general issue.
pwuertz commentedon Feb 18, 2015
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
jowr commentedon Feb 18, 2015
I am not sure, but doesn't this #4108 indicate that the PDF backend does not render the hatch pattern?
pwuertz commentedon Feb 18, 2015
@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 ;)
mdboom commentedon Feb 19, 2015
Interesting... PDF is
zlibcompressing 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.github-actions commentedon Jun 5, 2023
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!