On Fri, Aug 13, 2010 at 4:43 PM, Eric Firing <[email protected]> wrote:
> On 08/13/2010 10:35 AM, Benjamin Root wrote:
> > On Thu, Aug 12, 2010 at 4:46 PM, Eric Firing <[email protected]
> > <mailto:[email protected]>> 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...
Ben Root
import numpy as np
import matplotlib.pyplot as plt
y = np.random.randint(10, size=10)
plt.bar(np.arange(10), y, color=['none'])
plt.savefig('barcolor.png')
plt.savefig('barcolor.eps')
plt.show()
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
