matplotlib/matplotlib — pull request #1954 by Westacular (2013-04-27 22:14:01+00:00)
Title: Supporting different alphas for face and edge colours

This is a set of changes that solve the issues raised by #1899 and #1938.

### Linestyles

Ignore what I said before in #1899 about linestyles.

Turns out it was working correctly for patches, but the dashes and dots were all overlapping at `linewidth=5`. The culprit is a single line in `Patch.draw()` that was setting the gc to use 'projecting' capstyle. This capstyle causes the rendered length of dashes and dots to increase in proportion to the width, however, the spacing between them (which ignores the caps) remains constant. At `linewidth=5` the spaces are completely covered by the caps, making it look like `linestyle='solid'`.

Letting `capstyle='butt'`, the default, fixes this.

(Also, there was a bug in the PGF backend that was causing Collections (or anything with a custom dash pattern) to always use a solid linestyle. Fixed that.)

Also, for some reason, in the SVG header `stroke-linecap:square`(the translation of `capstyle='projecting'`) was being set as the default, even though the default for most objects is `butt`. This was causing a problem with the rendering of the PathCollection, because (at least on WebKit) the style for the collection, which did specify `butt`, was not overriding that default. The net effect was the same as the above problem for patches.

### Mixed Edge and Face Alpha Values

There was already stubs of logic (and a `_forced_alpha` attribute of GraphicsContext) for the notion that if an explicit alpha is set (through `gc.set_alpha()`) it should override any face and edge alphas, but otherwise, leave them be; however, it was largely ignored by most backends, each of which tended to do its own slightly different thing with regard which it recognized and how it handled them.

I've updated (and tested to varying degrees) the AGG, PDF, SVG, PGF, Mac OS X, and Cairo backends, along with various fixes to the backend bases and to the Patch class. As far as I can tell, that covers everything that's already paying attention to the `gc.get_alpha()` value.

I also fixed the bug (also discussed at #1938) where setting an alpha value on the patch would override `edgecolor='none'`. The new behaviour is that the value given to `alpha` is ignored by the edge colour if and only if `edgecolor='none'` exactly; `edgecolor=(x,x,x,0)` still gets overridden by `alpha`. This is the existing behaviour for `facecolor`, which I've not changed.

I've included the test (and changes) added by @pelson in #1899, along with correct results, and corrected the results of the `clip_to_bbox` test (which were previously affected by the alpha=x/edgecolor='none' bug). I've also added another test to check that the alpha attribute is overriding the alpha components of the face and edge colors.