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

[jemrobinson]

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]

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]

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.

[ngoldbaum]

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]

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]

ping @jkseppan

[jkseppan]

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.

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]

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.

[tacaswell]

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

[blalterman]

Any updates on this other than punting to 2.1?

[tacaswell]

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]

In what directory is backend_pdf.py?

[tacaswell]

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)

[github-actions]

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!

[jemrobinson]

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.pdf

[oscargus]

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.