On 08/13/2010 12:30 PM, Benjamin Root wrote: > > > On Fri, Aug 13, 2010 at 4:43 PM, Eric Firing <efir...@hawaii.edu > <mailto:efir...@hawaii.edu>> wrote: > > On 08/13/2010 10:35 AM, Benjamin Root wrote: > > On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing <efir...@hawaii.edu > <mailto:efir...@hawaii.edu> > > <mailto:efir...@hawaii.edu <mailto:efir...@hawaii.edu>>> wrote: > > > > On 08/12/2010 10:40 AM, Benjamin Root wrote: > > [...] > > > > > > > > >>> mcolor.colorConvertor.to_rgba_array('none') > > > > array([], shape=(0, 4), dtype=float64) > > > > > > > > >>> mcolor.colorConvertor.to_rgba_array(['none']) > > > > array([[ 0., 0., 0., 0.]]) > > > > > > > > >>> mcolor.colorConvertor.to_rgba_array('r') > > > > array([[ 1., 0., 0., 1.]]) > > > > > > > > Should this be regarded as a bug? > > > > > > Yes, 'none' should be handled uniformly by that method. > > Thanks for > > > tracking down actual source of the problem. Fixing it there > > is the > > > right thing to do. > > > > > > Eric > > > > > > > > > I am assuming that we would like this patched in the maintenance > > branch, > > > too, right? Also, because the doc and the output of the > > > .to_rgba_array() function is changing, should it be noted in the > > changelog? > > > > Yes, bugs should be squashed first in the maintenance branch, and > > svnmerge should be used to propagate the change to the trunk. If > > to_rgba_array is not treating "none" and ["none"] the same > way, that is > > a bug. > > > > But... now I'm looking at the to_rgba_array method, and > wondering why it > > is specifying that special case handling of "none". The > present code > > implementing that special case is mine, but I suspect I was just > > maintaining legacy behavior, as Darren had added this special > case > > explicitly to the docstring long before my code change. > > > > So it is looking more complicated than I thought. I suppose > the course > > of action most consistent with the idea of a maintenance > branch and a > > trunk would be to put the change in the trunk, since it is > changing the > > documented behavior of a key method. Then the choices for the > > maintenance branch would be to work around the behavior, as > in Ben > > North's patch, or to do nothing. If you work around it, I > think it will > > require special attention to keep svnmerge from erroneously > adding the > > workaround to the trunk the next time svnmerge is run. So, > if you > > choose to do that at all, I would suggest waiting until you > are sure how > > to handle that svnmerge aspect; maybe it is documented. > > > > Also, with the change to to_rgba_array in the trunk, you will > need to do > > some exploration to figure out whether any other code will > need to be > > changed to take advantage of it, or to allow for it. (I may > have had a > > reason for maintaining the bizarre legacy behavior the last > time I > > changed the code in that method...) > > > > Eric > > > > > > I have dug further about this. I have found that the hist() > function, > > as well as the bar family of functions are impacted by this issue. > > However, for hist(), if you try passing in 'none' for color in > the old > > version, it errors out saying that it needs some color info. > With this > > corrected version, it doesn't error, but there are no lines drawn as > > well (I have to see if that is another bug). > > > > The other place where I can see how this fix might cause issues > is with > > regards to Collections and the classes that derive from that. > > > > While I certainly think that the current behavior of > to_rgba_array() is > > wrong, I am starting to get hesitant about changing this because > there > > might be some sort of fundamental difference between how the backends > > are treating "array([], shape=(0, 4), dtype=float64)" and "array([0., > > 0., 0., 0.])". The first is really easy to use as a "don't draw > > anything" whereas the latter isn't that obvious to the backends. > > > > A particular case where this might cause trouble is for graphics > formats > > that do not support transparencies. Because "array([0., 0., 0., > 0.])" > > is fully transparent black, in formats like eps with a non-black > > background, the objects with this color will appear -- although, > it is > > already possible to do that with bar(..., color=['none']). > > But the ps backend intercepts the 0-alpha value and interprets it as > "don't draw at all". See the _draw_ps method: > > mightstroke = (gc.get_linewidth() > 0.0 and > (len(gc.get_rgb()) <= 3 or gc.get_rgb()[3] != 0.0)) > stroke = stroke and mightstroke > fill = (fill and rgbFace is not None and > (len(rgbFace) <= 3 or rgbFace[3] != 0.0)) > > Notice that both stroke and fill are checking for alpha != 0.0. > > > Yeah, well, try out my attached script. Then view the two files. > Something is wrong...
Correct--good catch. It looks I missed the patch draw method when I was reworking the handling of alpha. Let me try to straighten that out in the next day or two. Eric > > Ben Root ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
