John Hunter wrote: >>>>>> "Eric" == Eric Firing <[EMAIL PROTECTED]> writes: > > Eric> Try scatter(x, y, alpha=0) > > Hmm, this surprises me -- the edgecolor should respect alpha too, no? > I'm inclined to consider this a bug -- agree?
Maybe, but I am not sure it is so simple as that. At the very least, it illustrates the fact that all the possible combinations of rgb with separate alpha, rgba, faces, edges etc. is confusing, and that because of the organic growth of mpl combined with its support for backends with differing capabilities, there is not a single clear pattern of behavior. Which means we have more cleanup work to do at the very least. To be more ambitious (as if there weren't already enough pending grand ideas), some reconsideration and possible modification of the drawing model would be nice. > > The following should work in any backend that supports alpha > > scatter(rand(100), rand(100), s=50, facecolor=(1,1,1,0)) > > Though in older versions of mpl you will need to use a sequence of > facecolors since earlier versions of collections required all > properties to be sequences > > scatter(rand(100), rand(100), s=50, facecolor=((1,1,1,0),)) > > The problem with alpha solution is it won't work in postscript. We As you found out, using alpha=0 will work with postscript because it gets intercepted and turned into a "don't draw" before it hits the ps backend. I think I added this some time ago, probably when we had the last round of correspondence about this topic. > should either adopt the nocolor approach or add the 'fill' property > like we have in patches. One solution is to modify the color > converter to return None if the color is 'nocolor' which will allow us > to continue using None for 'use the default'. The downside is > modifying all the backends to respect it.... Regardless of any grander schemes, I think something like this (color converter modification) is worth doing and not too hard--not terribly different from what we already have--so I will look into it more closely. The color converter is already a bit complicated, partly because of legacy support for float-as-gray, which has been deprecated for quite a while now (in favor of 'float'-as-gray). If I add in 'nocolor' I would want to yank float-as-gray at the same time. For the backends, maybe it would be easier to let (-1,*,*,*) mean "don't draw"; if it has to be interpreted by C-code in some backends, always having a tuple and simply checking for a negative first element is much easier than having to check for None in place of a tuple. Eric > > JDH > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
