Moving to the devel list, since this concerns an internal API of
matplotlib. Thanks to Sourav for reporting this and to Eric for sending
the note to me.
Eric Firing <efiring@...> writes:
> Sourav K. Mandal wrote:
>> I have a simple problem: when outputting to PDF or SVG, alpha blending
>> does not work for the lines drawn by "contour". However, alpha blending
>> does work for the regions given by "contourf".
> You are right, this is a real bug, verified in svn.
The contour function creates a LineCollection, which gets drawn via
draw_path_collection, which the pdf backend inherits from backend_bases.
The default draw_path_collection (or _iter_collection really)
communicates the alpha of the *face color* only by setting the alpha
attribute of the GraphicsContext:
if rgbFace is not None and len(rgbFace)==4:
rgbFace = rgbFace[:3]
The alpha of the line only gets communicated via the fourth component of
the rgb attribute of the GraphicsContext, and currently the pdf backend
doesn't do anything with it.
I think this could be resolved in a number of ways, none of which is
obviously the perfect solution:
1. Add a check in _iter_collection for gc0._rgb having an alpha
component, similar to the current check for rgbFace, and set the
alpha attribute from that one too. (What if both rgbFace and gc0._rgb
have an alpha component?)
2. Make each backend's GraphicsContext set the alpha attribute from the
color. (If the alpha attribute is already set, how should they be
combined? Multiply, take the minimum, or what?)
3. Either get rid of the alpha attribute on the GraphicsContext and use
only rgba tuples within backends, or turn it into two attributes
(e.g. alphaFace and alphaStroke). (What to do with the frontend's
single alpha attribute?)
By the way, I have never really understood why rgbFace is given
separately from the GraphicsContext. Is this just an evolutionary
remnant or is there a deeper meaning for it?
Jouni K. Seppänen