Hi, I have just realized that the embedded pdf visualizer in my web browser show me the pdf correctly.
So I have to reformulate my issue:
I can correctly view the generated pdf with chromium pdf viewer
I can not correctly view the pdf with evince (GNOME Document Viewer 3.28.2)
I have done another test, I noticed that the generated pdf file is a "PDF-1.4" file.
I tried to to convert the same file as "PDF-1.5" version and now I can see all the hatching also with evince.
Does it exist any way to force plt.savefig to save the figure using PDF CompatibilityLevel 1.5?
Strikingly, the shared hatch_demo-PDF-1.5.pdf looks perfect in all tested pdf viewers and browsers (Firefox, Opera, Vivaldi, Foxit Reader, Acrobat, pdfSam, SumatraPDF).
However, I cannot reproduce the conversion. Trying to convert via ghostscript9.16 as >gswin64 -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -dPDFSETTINGS=/screen -dNOPAUSE -dQUIET -dBATCH -sOutputFile=hatch-demo15.pdf hatch_demo.pdf gives a pdf which looks bad in all tested viewers.
Curiously, I get similar result with mplcairo: chromium shows the hatches, mupdf and zathura don't, and okular only shows the round ones (second from the left).
@ImportanceOfBeingErnest I did the conversion like this:
I imported the file with inkscape (https://inkscape.org) and saved back (inkscape allows to "restrict to PDF version" 1.5).
I see, that means that it's not enough to just change the version, but to convert it to svg first and then save to pdf again. (Did you try with "restrict to version 1.4"? It might just work as well.)
The screenshots below are taken from Chrome. I can always see the hatches in Adobe Reader and the default Preview app in macOS with or without alpha=1.
CA: The current stroking alpha constant, specifying the constant shape or constant opacity value to be used for stroking operations in the transparent imaging model.
ca: Same as CA, but for nonstroking operations.
In terms of the code from matplotlib, it has something to do with the following lines:
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!
Activity
QuLogic commented on Oct 2, 2018
This is strange because ax.bar produces Rectangles in a BarContainer, and Rectangle hatching for PDF is definitely tested here:
matplotlib/lib/matplotlib/tests/test_simplification.py
Lines 221 to 226 in 7bcf618
The only difference is the example sets hatching after the object is created. But modifying the test to do the same still passes.
Perhaps something to do with the BarContainer is messing things up.
ftesser commented on Oct 2, 2018
Hi, I have just realized that the embedded pdf visualizer in my web browser show me the pdf correctly.
So I have to reformulate my issue:
I have done another test, I noticed that the generated pdf file is a "PDF-1.4" file.
I tried to to convert the same file as "PDF-1.5" version and now I can see all the hatching also with evince.
Does it exist any way to force plt.savefig to save the figure using PDF CompatibilityLevel 1.5?
For convenience I attach the "PDF-1.5" version here: hatch_demo-PDF-1.5.pdf
ImportanceOfBeingErnest commented on Oct 2, 2018
pdfSam: Blured hatching

Adobe Acrobat: No hatching at all

SumatraPDF: No hatching + some white lines
Strikingly, the shared hatch_demo-PDF-1.5.pdf looks perfect in all tested pdf viewers and browsers (Firefox, Opera, Vivaldi, Foxit Reader, Acrobat, pdfSam, SumatraPDF).
However, I cannot reproduce the conversion. Trying to convert via ghostscript9.16 as >gswin64 -sDEVICE=pdfwrite -dCompatibilityLevel=1.5 -dPDFSETTINGS=/screen -dNOPAUSE -dQUIET -dBATCH -sOutputFile=hatch-demo15.pdf hatch_demo.pdf gives a pdf which looks bad in all tested viewers.
Also using some online tool (https://docupub.de/pdfconvert) produces undesired output.
@ftesser Can you share how exactly you did the conversion?
anntzer commented on Oct 2, 2018
Curiously, I get similar result with mplcairo: chromium shows the hatches, mupdf and zathura don't, and okular only shows the round ones (second from the left).
ftesser commented on Oct 2, 2018
@ImportanceOfBeingErnest I did the conversion like this:
I imported the file with inkscape (https://inkscape.org) and saved back (inkscape allows to "restrict to PDF version" 1.5).
ImportanceOfBeingErnest commented on Oct 5, 2018
I see, that means that it's not enough to just change the version, but to convert it to svg first and then save to pdf again. (Did you try with "restrict to version 1.4"? It might just work as well.)
ftesser commented on Oct 5, 2018
@ImportanceOfBeingErnest: I confirm, the same inkscape procedure but with "restrict to PDF version" 1.4 works as well.
ImportanceOfBeingErnest commented on Oct 5, 2018
Good to know that it doesn't depend on the pdf version. It means that this is purely a problem of the pdf backend.
For a workaround one can indeed use inkscape as
def savepdfviasvg(fig, name, **kwargs): import subprocess fig.savefig(name+".svg", format="svg", **kwargs) incmd = ["inkscape", name+".svg", "--export-pdf={}.pdf".format(name), "--export-pdf-version=1.5"] #"--export-ignore-filters", subprocess.check_output(incmd) savepdfviasvg(fig, "hatchtestconv")which requires inkscape to live in the Path.
use inkscape workaround
export plots as pdf
xhain commented on Nov 18, 2019
Bump.
I'm having a similar issue here: hatching is not exported to PDF.
ShawnZhong commented on Sep 19, 2022
Adding alpha=1 to bar() seems to solve this problem.
The screenshots below are taken from Chrome. I can always see the hatches in Adobe Reader and the default Preview app in macOS with or without alpha=1.
ShawnZhong commented on Sep 19, 2022
Here is what I see when I open the following files in Chrome (105.0.5195.125 on arm64 macOS):
ShawnZhong commented on Sep 19, 2022
I dig into this a bit more and found that the alpha value is indeed the problem.
The following code snippet generates two images default.pdf and alpha1.0.pdf. Only the latter one properly shows the hatches in Chrome.
By diffing the generated PDF files. There is only a single line of difference:
One can also see this using a PDF parser:
The reference from http://res.icesoft.org/docs/icepdf/v4_4_0/core/org/icepdf/core/pobjects/graphics/ExtGState.html shows:
In terms of the code from matplotlib, it has something to do with the following lines:
matplotlib/lib/matplotlib/backends/backend_pdf.py
Lines 1991 to 1996 in 1d5221b
github-actions commented on Sep 20, 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!
oscargus commented on Sep 20, 2023
Thanks for these insights @ShawnZhong !
It seems like CA and ca is set here:
matplotlib/lib/matplotlib/backends/backend_pdf.py
Lines 1455 to 1466 in bd8198c
Which in turn is called from:
https://github.com/matplotlib/matplotlib/blob/bd8198c8b8b1a41c39e7f85ef164f7801682ecd0/lib/matplotlib/backends/backend_pdf.py#L2510C1-L2513C1
This is only called in:
matplotlib/lib/matplotlib/backends/backend_pdf.py
Lines 2589 to 2625 in bd8198c
(as part of self.commands)
There is a bit related to hatches where maybe alpha should be dealt with in some way...
Now, checking #17049, I may be somewhat correct, but the easiest thing is probably to build on that.
A-Vani commented on Mar 1, 2024
I still have this issue. An alternative is to generate svg files and then convert to pdf.
tacaswell commented on Apr 16, 2024
I can confirm some of the reports in this thread on ~current main: