Fix barplot color if none and alpha is set #11640
Conversation
lib/matplotlib/axes/_axes.py
Outdated
| itertools.repeat([0, 0, 0, 0])) | ||
|
|
||
| itertools.repeat('none')) | ||
| # |
|
yeah, I have a note about things like this in my tutorial. At the time I
wrote it, I said that "alpha" usually overrides the alpha channel of an
rgba tuple spec. Don't know if we have that policy written down anyplace,
but it probably came about from dealing with the bar() function.
…On Thu, Jul 12, 2018 at 1:55 PM, Paul Hobson ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In lib/matplotlib/axes/_axes.py
<#11640 (comment)>
:
> if edgecolor is None:
edgecolor = itertools.repeat(None)
else:
edgecolor = itertools.chain(
itertools.cycle(mcolors.to_rgba_array(edgecolor)),
# Fallback if edgecolor == "none".
- itertools.repeat([0, 0, 0, 0]))
-
+ itertools.repeat('none'))
+#
stray pound?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#11640 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARy-MbjXtpb3hF29ESKVlpTH2ndhNXoks5uF42bgaJpZM4VL9nq>
.
|
9a2c1dc to
dd52123
Compare
|
@WeatherGod I don't know what you want to say with your comment. It's ok, that alpha overrides the alpha channel for normal colors. However, I consider it an implementation detail that |
|
My comment was in response to yours about the color resolution needing to
be rethought. I was pointing out that we do seem to have some sort of
semi-official policy regarding this (or else I wouldn't have written it
down). I just wish I could remember where the basis for my statement in the
tutorial came from.
…On Thu, Jul 12, 2018 at 7:18 PM, Tim Hoffmann ***@***.***> wrote:
@WeatherGod <https://github.com/WeatherGod> I don't know what you want to
say with your comment.
It's ok, that alpha overrides the alpha channel for normal colors.
However, I consider it an implementation detail that color='none' is
realized as a fully transparent rgba tuple. Logically 'no color' should be
invisible irrespective of its alpha.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#11640 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AARy-Mx0pUdrPjojYyqNFPsdySspBxR9ks5uF9k5gaJpZM4VL9nq>
.
|
I'm not a huge fan of this convention, but I guess its a quick way to change the alpha of the whole rectangle w/o futzing w/ the rgba values. I'm not clear though what happens if we specify: The user at some point thought facecolor should be more transparent than edgecolor, so should alpha be multiplied as a quick way to make both more transparent? |
|
@jklymak a relative alpha would be too clever. It's even hard to define it in a consistent and intuitive way. Is only one of edgecolor or facecolor absolute? If so which? What should happen for all the combinations of each opaque, semi- or fully transparent? Can you make IMO, using alpha to define foth facecolor and edgecolor absolutely is the more reasonable choice. |
PR Summary
Fixes #11628.
The actual fix is a bit hacky. It relies on the fact that in
Rectangle(edgecolor='none', alpha=0.3)alpha is applied before the color is resolved to [0,0,0,0]. The reverse order would overwrite the alpha of the edgecolor. Maybe the whole color resolution has to be thought through at some point.Anyway the fix works and has a test. So, it will blow up if the color resolution in Rectangle would be changed. This is good enough for now.
PR Checklist