Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Specifying dictionary argument with dict() or braces matters in set_bbox #1934

Closed
lguez opened this Issue Apr 22, 2013 · 6 comments

Comments

Projects
None yet
4 participants

lguez commented Apr 22, 2013

In matplotlib home page, there is a link to a tutorial by Nicolas Rougier. In the section of the tutorial entitled "Devil is in the details", the script:

http://www.loria.fr/~rougier/teaching/matplotlib/scripts/exercice_10.py

produces the figure displayed on the web page. Line 48 of the script is:

label.set_bbox(dict(facecolor='white', edgecolor='None', alpha=0.65 ))

If we replace this line by:

label.set_bbox({"facecolor": "white", "edgecolor": "None","alpha":0.65})

then the edgecolor request is not taken into account. The two statements above should be equivalent. The author of the tutorial, Nicolas Rougier, is surprised too. People on stackoverflow think it is a matplotlib bug:

http://stackoverflow.com/questions/16107832/specifying-dictionary-argument-with-dict-or-braces-matters-in-set-bbox

Member

WeatherGod commented Apr 23, 2013

From the bit of digging I have done on this, there doesn't seem to be
anything in the text.py codebase that processes a property dictionary in
such a way that order would effect it. That would mean that this problem
is merely the tip of an iceberg. One way to really test this hypothesis of
order-dependent processing is to utilize OrderedDictionaries and try out
every possible combination of those entries and see which ones work and
which ones don't. Then, I would try to see if the problem could be
reproduced with a simple patch object,

Contributor

cimarronm commented Apr 23, 2013

The problem is not with the way you instantiate a dictionary but the order. If I run the test program, sometimes I see the edge and sometimes not depending on the random ordering of the dictionary.

The issue arrises when alpha comes after edgecolor and the fact that there is no special edgecolor for "none". Instead when one sets edgecolor to "none" it gets transfered to a RGBA tuple of (0,0,0,0). Then when alpha is set it makes it (0,0,0,0.65) in the example (i.e. black with an alpha of 0.65) which is why the edge shows up.

I believe the solution is to actually allow colors of None but code would have to change to accept and interpret a None value in addition to the RGBA tuple, i.e. a color of none and black with zero alpha are indeed different.

Member

pelson commented May 13, 2013

@cimarronm - is this now fixed?

lguez commented May 13, 2013

Thank you. Am I supposed to close this issue myself? (I do not have the update with the correction myself.)

Contributor

cimarronm commented May 14, 2013

@pelson: I tested it and it is fixed thanks to the good work from @Westacular

Member

pelson commented May 15, 2013

Great. thanks for the update.

@pelson pelson closed this May 15, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment