Skip to content

Fill color is always opaque in the pdf backend if there is a hatch pattern #3841

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
jemrobinson opened this issue Nov 24, 2014 · 16 comments
Closed

Fill color is always opaque in the pdf backend if there is a hatch pattern #3841

jemrobinson opened this issue Nov 24, 2014 · 16 comments
Assignees
@mdboom
Labels
backend: pdf status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. status: confirmed bug status: inactive Marked by the “Stale” Github Action topic: hatch
Milestone
future releases

Comments

@jemrobinson
Copy link

I've posted this issue on StackOverflow as: http://stackoverflow.com/questions/27094747/

The basic problem is that transparency information isn't being correctly to PDFs when hatching is used.

I'm running in OS X (Yosemite) with the default MacOSX matplotlib backend and using matplotlib 1.4.1. Is there any reason why this setup should fail to produce transparent PDF output? This used to work in the past (with OS X Mavericks and an earlier version of matplotlib) but I'm not sure exactly what change has caused this problem.

If the following code is run, the problem can be seen in with_hatch.pdf, but not in any of the other output files.

#! /usr/bin/env python
import matplotlib.pyplot as plt

fig = plt.figure( figsize=(6, 6), dpi=100, facecolor='white' )
ax = fig.add_axes( [0.15, 0.1, 0.8, 0.85] )

bin_edges = [0.0, 0.5, 0.5, 1.0, 1.0, 1.5, 1.5, 2.0, 2.0, 2.5, 2.5, 3.0, 3.0, 3.5, 3.5, 4.0, 4.0, 4.5, 4.5, 5.0, 5.0, 5.5, 5.5, 6.0, 6.0, 7.0, 7.0, 8.0]
y_low     = [0.9581631739289882, 0.9581631739289882, 0.8966054746563691, 0.8966054746563691, 0.8369962202270926, 0.8369962202270926, 0.7824880045351325, 0.7824880045351325, 0.7231695683685057, 0.7231695683685057, 0.6673767757896321, 0.6673767757896321, 0.6083447707111752, 0.6083447707111752, 0.5602384968623321, 0.5602384968623321, 0.5109567893600544, 0.5109567893600544, 0.4707872827805316, 0.4707872827805316, 0.4304527769718274, 0.4304527769718274, 0.39024135798617826, 0.39024135798617826, 0.3593458738615755, 0.3593458738615755, 0.3275704585658484, 0.3275704585658484]
y_high    = [0.9762065896798683, 0.9762065896798683, 0.9227253843496172, 0.9227253843496172, 0.8738222849514, 0.8738222849514, 0.8299500683866315, 0.8299500683866315, 0.7810616940586165, 0.7810616940586165, 0.7357506442258693, 0.7357506442258693, 0.6852756294051707, 0.6852756294051707, 0.6441575476130643, 0.6441575476130643, 0.5987788803224889, 0.5987788803224889, 0.5630257208701298, 0.5630257208701298, 0.5274860424153797, 0.5274860424153797, 0.4915335923551736, 0.4915335923551736, 0.46502435263727837, 0.46502435263727837, 0.43196895235913746, 0.43196895235913746]

ax.fill_between( bin_edges, y_low, y_high, facecolor='green', edgecolor='white', alpha=0.4 )

plt.savefig( 'without_hatch.pdf' )
plt.savefig( 'without_hatch.png' )

ax.fill_between( bin_edges, y_low, y_high, facecolor='green', edgecolor='white', hatch='xxxx', alpha=0.4 )

plt.savefig( 'with_hatch.pdf' )
plt.savefig( 'with_hatch.png' )
@tacaswell tacaswell modified the milestone: v1.4.3 Nov 25, 2014
@tacaswell tacaswell modified the milestones: v1.4.x, v1.4.3 Jan 31, 2015
@tacaswell
Copy link
Member

punting to 1.4.x, this isn't going to get done immediately and I don't want to block 1.4.3 on this. Any protests?

@mdboom mdboom self-assigned this Feb 2, 2015
@mdboom
Copy link
Member

mdboom commented Feb 2, 2015

I think punting is fine -- I'm just noticing this now and might have some time to look at it soon, but don't let this hold you up.

@tacaswell tacaswell modified the milestones: v1.4.x, 1.5.0 Feb 7, 2015
@ngoldbaum
Copy link
Contributor

I just ran into this as well. Is there any sort of workaround? I guess I could just save as png and include the figure I'm having issues with as a raster image in my paper.

@efiring
Copy link
Member

efiring commented Jun 24, 2015

I'm seeing the same thing in the png as in the pdf. I suspect the reason you are seeing them differently is that the hatch pattern is quite fine, so in conjunction with antialiasing, it is lightening most of the pixels. This is seen most clearly when you zoom in.

@tacaswell
Copy link
Member

ping @jkseppan

@jkseppan
Copy link
Member

I think I see the problem: the hatch pattern stream does not set alpha parameters, which in PDF requires using an ExtGState dictionary. If I hand-edit the PDF file so that the pattern stream refers to the page's ExtGState dictionary and sets the relevant state, the output color looks closer to the PNG file.

image

But note those horizontal and vertical lines, which occur at one-inch intervals, at least when viewed in Apple's Preview.app. I don't think we can get a good result when filling with a transparent color if we use tiling patterns, like all the PDF hatch patterns currently are (cf. #1188).

@jkseppan
Copy link
Member

The operations of filling with a color and filling with a hatch pattern are done with the same operator in pdf, and unfortunately the pdf backend has an inbuilt assumption that we do at most one of these. When we do both, the background color is included in the fill pattern, which is a mistake - we should be able to do both operations independently.

@jkseppan jkseppan changed the title Matplotlib plots lose transparency when saving as .pdf Fill color is always opaque in the pdf backend if there is a hatch pattern Jul 17, 2015
@tacaswell tacaswell modified the milestones: proposed next point release, next point release Jul 22, 2015
@tacaswell
Copy link
Member

Moved out of 1.5 milestone as this sounds like it might require major work to the pdf backend?

@blalterman
Copy link

Any updates on this other than punting to 2.1?

@tacaswell
Copy link
Member

I do not believe so.

It looks like the hatch is written out by a method writeHatch in backend_pdf.py. This is probably what needs to be picked apart.

pull requests are always welcome!

@blalterman
Copy link

In what directory is backend_pdf.py?

@tacaswell
Copy link
Member

https://github.com/matplotlib/matplotlib/blob/master/lib/matplotlib/backends/backend_pdf.py

On Mon, May 9, 2016 at 11:50 PM balterman notifications@github.com wrote:

In what directory is backend_pdf.py?

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#3841 (comment)

@efiring efiring mentioned this issue Jul 4, 2017
Closed
@tacaswell tacaswell modified the milestones: 2.1 (next point release), 2.2 (next next feature release) Oct 3, 2017
@mnmelo mnmelo mentioned this issue Mar 23, 2020
Open
@oscargus oscargus mentioned this issue Apr 19, 2022
Closed
@github-actions
Copy link

github-actions bot commented 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!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Jun 5, 2023
@jemrobinson
Copy link
Author

Just tested with:

  • Python 3.11.3
  • matplotlib 3.7.1

and this seems to be solved. See the attached PNG and PDF below.

with_hatch
with_hatch.pdf

@oscargus
Copy link
Member

oscargus commented Jun 5, 2023

Sounds good! Although not really clear what fixed it.

There is a PR #17049 that is "almost done" which would fix it. Plus that there are some issues where different PDF renderers show the information differently.

I'll leave it open and then we can possibly close it once we are certain that it is fully fixed and which PR did it.

@oscargus oscargus removed the status: inactive Marked by the “Stale” Github Action label Jun 5, 2023
@github-actions GitHub Actions
Copy link

github-actions bot commented Jun 5, 2024

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!

@github-actions github-actions bot added the status: inactive Marked by the “Stale” Github Action label Jun 5, 2024
@github-actions github-actions bot added the status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. label Jul 5, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@mdboom mdboom

Labels
backend: pdf status: closed as inactive Issues closed by the "Stale" Github Action. Please comment on any you think should still be open. status: confirmed bug status: inactive Marked by the “Stale” Github Action topic: hatch
Projects
None yet
Milestone
future releases
Development

No branches or pull requests
8 participants
@mdboom @efiring @jkseppan @tacaswell @ngoldbaum @jemrobinson @oscargus @blalterman