matplotlib-users Mailing List for matplotlib (Page 17)

On Thu, Oct 1, 2009 at 5:29 PM, Ernest Adrogué <ead...@gm...> wrote:
> Hello all,
>
> What is the best way to plot a 2d histogram?
> (Note that a 2d histogram is a histogram of a bivariate variable,
> so it's got to be a 3d plot.)
>
> Ideally, it should look somewhat like this:
> http://www.desy.de/~mraue/public/rootTutorial/v0.2/histogram02.gif
>
> For now, I have tried to do surface plots, one for each "bin",
> but this way you only get the tops of a series of imaginary columns
> and it looks a bit namby-pamby if you know what I mean.
>
> Any idea will be appreciated.
>
> --
> Ernest
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
Although it is not an exact histogram, if you are you looking for a
Pythonic alternative you might consider using Mayavi. It has ready
barchart plotting functionality. Probably with some effort a 2D
histogram as you linked might be created.
http://code.enthought.com/projects/mayavi/docs/development/html/mayavi/auto/mlab_helper_functions.html#barchart
-- 
Gökhan

Hello all,
What is the best way to plot a 2d histogram?
(Note that a 2d histogram is a histogram of a bivariate variable,
so it's got to be a 3d plot.)
Ideally, it should look somewhat like this:
http://www.desy.de/~mraue/public/rootTutorial/v0.2/histogram02.gif
For now, I have tried to do surface plots, one for each "bin",
but this way you only get the tops of a series of imaginary columns
and it looks a bit namby-pamby if you know what I mean.
Any idea will be appreciated.
-- 
Ernest

Eric Firing wrote:
> I have committed a change to svn trunk, so that if you change the
> above to
> 
> q = plt.quiver([0],[0], [1], [1], scale_units='xy', angles='xy', scale=1)
Eric,
You might recall that I spent a bit of time making a "stick plot" with 
quiver. I go to work OK, but I couldn't do exactly what I wanted. I 
think gets closer, but I"m not sure it quite gets there:
How exactly are the arrows scaled with scale_units='xy'? What I'd like 
is for the length of the arrow to the the y scale only -- the x scale it 
irrelevant (x is time, y is velocity). Can I do that with this?
> (Maybe I should add "width_units", identical to "units", and deprecate 
> the latter; this might make the meanings of the kwargs clearer.)
+1
But if you're doing that, you may want to make more changes, also -- you 
might as well do them all at once.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

sorry, I forget the patch
very simple.no big deal.
On Thu, Oct 1, 2009 at 2:04 PM, Gewton Jhames <gj...@gm...> wrote:
> worked fine.
>
>
> On Thu, Oct 1, 2009 at 1:10 PM, Michael Droettboom <md...@st...>wrote:
>
>> I'm not quite clear on what changes you made. Can you provide a patch?
>>
>> Also -- have you tested the change I committed here:
>>
>>
>> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/patches.py?r1=7443&r2=7837&pathrev=7837
>>
>> Cheers,
>> Mike
>>
>> Gewton Jhames wrote:
>>
>>> "solved".
>>> In the system with the 0.99 version, in the file axes.py, class Axes,
>>> method pie, the shadow is created:
>>> if shadow:
>>> # make sure to add a shadow after the call to
>>> # add_patch so the figure and transform props will be
>>> # set
>>> shad = mpatches.Shadow(w, -0.02, -0.02,
>>> )
>>> shad.set_zorder(0.9*w.get_zorder())
>>> self.add_patch(shad)
>>> having a look at matplotlib.patches.Shadow we can see a bit of keyword
>>> parameters. I passed this parameters when creating the Pie chart, and this
>>> method send the parameters when creating the shadow (piece of code above).
>>> So, I modifed the signature of the method pie and the line that creates a
>>> shadow (/shad = mpatches.Shadow(w, -0.02 .../ ).
>>>
>>> I put "solved" quoted because was not a very beautiful soluction, but, I
>>> think was the best one for this case.
>>>
>>> On Thu, Oct 1, 2009 at 10:13 AM, Gewton Jhames <gj...@gm...<mailto:
>>> gj...@gm...>> wrote:
>>>
>>> OK, yesterday I was taking a look to the patch module. then, I
>>> went home.
>>> Today, I'll continue to look at these properties of alpha.
>>> because, yes, that's what's happening. one have alpha .5 and the
>>> other, 1.
>>> Answering Mike's question: the first system (the one I've wrote
>>> the code) is ubuntu 9.04, the other (with a newer version) is
>>> ubuntu server 8.04 LTS.Doesn't make any difference.
>>>
>>>
>>> On Thu, Oct 1, 2009 at 9:37 AM, Michael Droettboom
>>> <md...@st... <mailto:md...@st...>> wrote:
>>>
>>> Yeah, alpha handling is a bit of a mess -- it should probably
>>> be revamped in light of the fact that most places now accept
>>> rgba. We just need to decide if there is a good solution that
>>> doesn't break backward compatibility, or whether we should
>>> just break compatibility (e.g. remove set/get_alpha) moving
>>> forward.
>>>
>>> As for the current problem, I'll add a set_alpha call to the
>>> Shadow class.
>>>
>>> Mike
>>>
>>>
>>> Jae-Joon Lee wrote:
>>>
>>> Mike,
>>>
>>> I think this maybe related with some changes in how alpha
>>> is set (this
>>> happened sometime early this year I guess).
>>>
>>> I think the issue here is, when the shadow patch is
>>> created, it sets
>>> its facecolor with alpha=0.5., i.e., its _facecolor is
>>> something like
>>> (r, g, b, 0.5). But, shadow._alpha = 1 still. And later
>>> when the
>>> shadow is drawn, the alpha of the facecolor is simply
>>> overridden by
>>> _alpha. Given that alpha=0.5 is intended, I think this is
>>> a bug. But
>>> I'm not sure what is the preferred way to fix this.
>>>
>>> I think this is a general issue of Patch classes. While
>>> the alpha
>>> values can be set with facecolor and edgecolor, they are
>>> simply
>>> overridden by _alpha. If this behavior is necessary and
>>> intended, we
>>> should change the Shadow class to set its alpha correctly.
>>>
>>> I, personally, want to have different alphas for the
>>> facecolor and
>>> edgecolor, which cannot be done with the current approach.
>>> However, I
>>> believe the current backend api itself (draw_path) does
>>> not allow
>>> different alphas for edgecolor and facecolor, so it may
>>> best stick to
>>> the current behavior.
>>>
>>> Regards,
>>>
>>> -JJ
>>>
>>>
>>> On Wed, Sep 30, 2009 at 4:51 PM, Michael Droettboom
>>> <md...@st... <mailto:md...@st...>> wrote:
>>>
>>> I'm still not seeing a difference between 0.98.5 and
>>> 0.99.1 here. I
>>> further investigation of the code shows that there
>>> were no changes in
>>> how the shadow color is computed between these
>>> versions. Is it possible
>>> you're using an even earlier version? You can
>>> determine it using:
>>>
>>> >>> import matplotlib
>>> >>> matplotlib.__version__
>>>
>>> Are there any other differences between the two
>>> installations, such as
>>> backend?
>>>
>>> Cheers,
>>> Mike
>>>
>>> Gewton Jhames wrote:
>>>
>>> sorry, this is the script:
>>>
>>> #!/usr/bin/python
>>> # -*- coding: utf-8 -*-
>>> from pylab import *
>>>
>>> from matplotlib.pyplot import figure, show
>>> from matplotlib.patches import Ellipse
>>> import numpy as np
>>>
>>> figure(1, figsize=(6,6), facecolor='#ffffff')
>>> ax = axes([0.1, 0.1, 0.8, 0.8])
>>>
>>> labels = 'label1', 'label2'
>>> fracs = [40, 60]
>>> colors = ['#E3AB9C', '#C6E9F8']
>>>
>>> explode=(0, 0.05)
>>>
>>> plots = pie(fracs, explode=explode, labels=labels,
>>> colors=colors,
>>> autopct='%0.2f%%', shadow=True)
>>> plots[0][0].set_edgecolor('#E4471A')
>>> plots[0][1].set_edgecolor('#1AA8E4')
>>> title('Raining Hogs and Dogs',
>>> bbox={'facecolor':'0.8', 'pad':5})
>>>
>>>
>>> show()
>>>
>>>
>>> On Wed, Sep 30, 2009 at 5:19 PM, Michael
>>> Droettboom <md...@st... <mailto:md...@st...>
>>> <mailto:md...@st... <mailto:md...@st...>>>
>>>
>>> wrote:
>>>
>>> Can you provide the script that produces these
>>> graphs? I don't
>>> see any difference between 0.98.5 and 0.99.1 on
>>> the included
>>> pie_demo.py example. Which backend are you using?
>>>
>>> Mike
>>>
>>> Gewton Jhames wrote:
>>>
>>> Hello, I'm having two different results in
>>> the shadow of a
>>> graph. I develop the graph in a system with
>>> matplotlib 0.98.5.
>>> When I put the code in other machine, with
>>> the same version of
>>> libpng, but with matplotlib 0.99.0, the
>>> shadow of the graph
>>> has changed to a real bad one.
>>>
>>> In attachment, the two generated graphs. I
>>> wish that the
>>> graph's shadown generated in 0.99 be the
>>> same of 0.98.5.
>>>
>>> Well, see the attachment and you'll understand.
>>> thanks.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry&reg;
>>> Developer Conference
>>> in SF, CA
>>> is the only developer event you need to
>>> attend this year.
>>> Jumpstart your
>>> developing skills, take BlackBerry mobile
>>> applications to
>>> market and stay ahead of the curve. Join us
>>> from November
>>> 9&#45;12, 2009. Register now&#33;
>>> http://p.sf.net/sfu/devconf
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> <mailto:Mat...@li...>
>>> <mailto:
>>> Mat...@li...
>>> <mailto:Mat...@li...>>
>>>
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry&reg; Developer
>>> Conference in SF, CA
>>> is the only developer event you need to attend this
>>> year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications
>>> to market and stay
>>> ahead of the curve. Join us from November 9&#45;12,
>>> 2009. Register now&#33;
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> <mailto:Mat...@li...>
>>>
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>>
>>> -- Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>>
>>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>

Hi,
 I am trying to plot a graph and color nodes in a loop. So far, the
for-loop I am using can color them. But, I am able to color them using a
single color. I want to color the nodes differently for each iteration of
the for-loop. How do I do that?
My code so far:
============================================
 nx.draw(G,pos, node_color='w', edge_color='k',
 width=0.5,with_labels=True,alpha=0.8)
 time.sleep(1)
 # Now, begin updating by coloring nodes and edges
 for i,nlist in enumerate(MIS_levels):
 # update-color each level nodes
 nx.draw_networkx_nodes(G,pos,nodelist=nlist,
 node_color='b',node_size=200,alpha=0.8)
 time.sleep(1)
 if i < len(elist):
 nx.draw_networkx_edges(G,pos, edgelist=elist[i],edge_color='r',
 width=2,with_labels=True,alpha=0.8)
 plt.plot()
 time.sleep(1)
========================================================
The above code colors the nodes blue and the edges r. I want to options:
1 --- For each iteration, I want the nodes to be colored in diminishing
shade (like Red_r).
2 --- For each iteration, I want a separate coloring of the nodes.
Any ideas, suggestions are very much appreicated.
Thanks,
Sri.

hi all,
i am parsing a csv text file as follows:
data = genfromtxt(filename, delimiter=delimiter, dtype=None, names=True)
this returns an array. sometimes though i want to access the element
that has value x in, say, the first column. i usually do this like
this:
nonzero(data['first_column'] == x)
which returns the indices that match. is there a more efficient way to
do this? i'm willing to assume that the values in this column are
unique, so a dict like structure might work. however, i prefer to use
a built in function that might do something like this... is there a
way to do this with the array returned by genfromtxt for example?
thank you.

worked fine.
On Thu, Oct 1, 2009 at 1:10 PM, Michael Droettboom <md...@st...> wrote:
> I'm not quite clear on what changes you made. Can you provide a patch?
>
> Also -- have you tested the change I committed here:
>
>
> http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/patches.py?r1=7443&r2=7837&pathrev=7837
>
> Cheers,
> Mike
>
> Gewton Jhames wrote:
>
>> "solved".
>> In the system with the 0.99 version, in the file axes.py, class Axes,
>> method pie, the shadow is created:
>> if shadow:
>> # make sure to add a shadow after the call to
>> # add_patch so the figure and transform props will be
>> # set
>> shad = mpatches.Shadow(w, -0.02, -0.02,
>> )
>> shad.set_zorder(0.9*w.get_zorder())
>> self.add_patch(shad)
>> having a look at matplotlib.patches.Shadow we can see a bit of keyword
>> parameters. I passed this parameters when creating the Pie chart, and this
>> method send the parameters when creating the shadow (piece of code above).
>> So, I modifed the signature of the method pie and the line that creates a
>> shadow (/shad = mpatches.Shadow(w, -0.02 .../ ).
>>
>> I put "solved" quoted because was not a very beautiful soluction, but, I
>> think was the best one for this case.
>>
>> On Thu, Oct 1, 2009 at 10:13 AM, Gewton Jhames <gj...@gm...<mailto:
>> gj...@gm...>> wrote:
>>
>> OK, yesterday I was taking a look to the patch module. then, I
>> went home.
>> Today, I'll continue to look at these properties of alpha.
>> because, yes, that's what's happening. one have alpha .5 and the
>> other, 1.
>> Answering Mike's question: the first system (the one I've wrote
>> the code) is ubuntu 9.04, the other (with a newer version) is
>> ubuntu server 8.04 LTS.Doesn't make any difference.
>>
>>
>> On Thu, Oct 1, 2009 at 9:37 AM, Michael Droettboom
>> <md...@st... <mailto:md...@st...>> wrote:
>>
>> Yeah, alpha handling is a bit of a mess -- it should probably
>> be revamped in light of the fact that most places now accept
>> rgba. We just need to decide if there is a good solution that
>> doesn't break backward compatibility, or whether we should
>> just break compatibility (e.g. remove set/get_alpha) moving
>> forward.
>>
>> As for the current problem, I'll add a set_alpha call to the
>> Shadow class.
>>
>> Mike
>>
>>
>> Jae-Joon Lee wrote:
>>
>> Mike,
>>
>> I think this maybe related with some changes in how alpha
>> is set (this
>> happened sometime early this year I guess).
>>
>> I think the issue here is, when the shadow patch is
>> created, it sets
>> its facecolor with alpha=0.5., i.e., its _facecolor is
>> something like
>> (r, g, b, 0.5). But, shadow._alpha = 1 still. And later
>> when the
>> shadow is drawn, the alpha of the facecolor is simply
>> overridden by
>> _alpha. Given that alpha=0.5 is intended, I think this is
>> a bug. But
>> I'm not sure what is the preferred way to fix this.
>>
>> I think this is a general issue of Patch classes. While
>> the alpha
>> values can be set with facecolor and edgecolor, they are
>> simply
>> overridden by _alpha. If this behavior is necessary and
>> intended, we
>> should change the Shadow class to set its alpha correctly.
>>
>> I, personally, want to have different alphas for the
>> facecolor and
>> edgecolor, which cannot be done with the current approach.
>> However, I
>> believe the current backend api itself (draw_path) does
>> not allow
>> different alphas for edgecolor and facecolor, so it may
>> best stick to
>> the current behavior.
>>
>> Regards,
>>
>> -JJ
>>
>>
>> On Wed, Sep 30, 2009 at 4:51 PM, Michael Droettboom
>> <md...@st... <mailto:md...@st...>> wrote:
>>
>> I'm still not seeing a difference between 0.98.5 and
>> 0.99.1 here. I
>> further investigation of the code shows that there
>> were no changes in
>> how the shadow color is computed between these
>> versions. Is it possible
>> you're using an even earlier version? You can
>> determine it using:
>>
>> >>> import matplotlib
>> >>> matplotlib.__version__
>>
>> Are there any other differences between the two
>> installations, such as
>> backend?
>>
>> Cheers,
>> Mike
>>
>> Gewton Jhames wrote:
>>
>> sorry, this is the script:
>>
>> #!/usr/bin/python
>> # -*- coding: utf-8 -*-
>> from pylab import *
>>
>> from matplotlib.pyplot import figure, show
>> from matplotlib.patches import Ellipse
>> import numpy as np
>>
>> figure(1, figsize=(6,6), facecolor='#ffffff')
>> ax = axes([0.1, 0.1, 0.8, 0.8])
>>
>> labels = 'label1', 'label2'
>> fracs = [40, 60]
>> colors = ['#E3AB9C', '#C6E9F8']
>>
>> explode=(0, 0.05)
>>
>> plots = pie(fracs, explode=explode, labels=labels,
>> colors=colors,
>> autopct='%0.2f%%', shadow=True)
>> plots[0][0].set_edgecolor('#E4471A')
>> plots[0][1].set_edgecolor('#1AA8E4')
>> title('Raining Hogs and Dogs',
>> bbox={'facecolor':'0.8', 'pad':5})
>>
>>
>> show()
>>
>>
>> On Wed, Sep 30, 2009 at 5:19 PM, Michael
>> Droettboom <md...@st... <mailto:md...@st...>
>> <mailto:md...@st... <mailto:md...@st...>>>
>>
>> wrote:
>>
>> Can you provide the script that produces these
>> graphs? I don't
>> see any difference between 0.98.5 and 0.99.1 on
>> the included
>> pie_demo.py example. Which backend are you using?
>>
>> Mike
>>
>> Gewton Jhames wrote:
>>
>> Hello, I'm having two different results in
>> the shadow of a
>> graph. I develop the graph in a system with
>> matplotlib 0.98.5.
>> When I put the code in other machine, with
>> the same version of
>> libpng, but with matplotlib 0.99.0, the
>> shadow of the graph
>> has changed to a real bad one.
>>
>> In attachment, the two generated graphs. I
>> wish that the
>> graph's shadown generated in 0.99 be the
>> same of 0.98.5.
>>
>> Well, see the attachment and you'll understand.
>> thanks.
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg;
>> Developer Conference
>> in SF, CA
>> is the only developer event you need to
>> attend this year.
>> Jumpstart your
>> developing skills, take BlackBerry mobile
>> applications to
>> market and stay ahead of the curve. Join us
>> from November
>> 9&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> <mailto:Mat...@li...>
>> <mailto:
>> Mat...@li...
>> <mailto:Mat...@li...>>
>>
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer
>> Conference in SF, CA
>> is the only developer event you need to attend this
>> year. Jumpstart your
>> developing skills, take BlackBerry mobile applications
>> to market and stay
>> ahead of the curve. Join us from November 9&#45;12,
>> 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> <mailto:Mat...@li...>
>>
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>>
>> -- Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>>
>>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

Hi everyone,
We're having a problem in Sage where if we specify the dpi of a figure, 
the bottom of the figure is cut off, but only the first time we save 
it. If we save the figure again, with the same arguments, the resulting 
image looks fine. I'm puzzled whether this is a Sage problem or a 
problem with interfacing with matplotlib, since it only happens when we 
are launch Sage (as opposed to just launching the ipython that Sage uses).
More details:
Running the following code in the Sage notebook or from the Sage command 
line gives a figure in which the bottom is cut off and the file is 12K 
instead of 13K. While firefox displays an image in which the bottom is 
cut off, eog (the gnome image viewer) doesn't even display the image, so 
I think the image might be corrupted. When I open the image with 
Konqueror, it seems like the cut off part of the image (about the lower 
quarter of the image) is completely transparent. I've attached the cut 
off image.
import matplotlib.pyplot as plt
import numpy
plt.figure()
plt.plot(numpy.arange(0,1.1,0.01))
plt.savefig('foo.png',dpi=72) 
However, if we immediately save the figure again:
plt.savefig('foo.png',dpi=72) 
the resulting image looks fine (i.e., the bottom is not cut off, the 
file is 13K, and eog displays it).
If we run the same code again using "sage -ipython" (which just launches 
Sage's ipython, without any Sage initialization), the same code:
import matplotlib.pyplot as plt
import numpy
plt.figure()
plt.plot(numpy.arange(0,1.1,0.01))
plt.savefig('foo.png',dpi=72) 
works just fine (i.e., the file is correct and complete).
I'm puzzled since we are just using matplotlib commands, not any Sage 
commands. If we remove the "dpi=72" argument from savefig, everything 
works perfectly in all cases. My guess is that there is some sort of 
configuration option that Sage is setting when it starts up, but that is 
overridden or something after the first time matplotlib saves a figure. 
But I have no clue what sort of thing to look for. Does anyone have an 
idea of what could be causing this issue?
Thanks,
Jason
--
Jason Grout

I'm not quite clear on what changes you made. Can you provide a patch?
Also -- have you tested the change I committed here:
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/branches/v0_99_maint/lib/matplotlib/patches.py?r1=7443&r2=7837&pathrev=7837
Cheers,
Mike
Gewton Jhames wrote:
> "solved".
> In the system with the 0.99 version, in the file axes.py, class Axes, 
> method pie, the shadow is created:
> if shadow:
> # make sure to add a shadow after the call to
> # add_patch so the figure and transform props will be
> # set
> shad = mpatches.Shadow(w, -0.02, -0.02,
> )
> shad.set_zorder(0.9*w.get_zorder())
> self.add_patch(shad)
> having a look at matplotlib.patches.Shadow we can see a bit of keyword 
> parameters. I passed this parameters when creating the Pie chart, and 
> this method send the parameters when creating the shadow (piece of 
> code above).
> So, I modifed the signature of the method pie and the line that 
> creates a shadow (/shad = mpatches.Shadow(w, -0.02 .../ ).
>
> I put "solved" quoted because was not a very beautiful soluction, but, 
> I think was the best one for this case.
>
> On Thu, Oct 1, 2009 at 10:13 AM, Gewton Jhames <gj...@gm... 
> <mailto:gj...@gm...>> wrote:
>
> OK, yesterday I was taking a look to the patch module. then, I
> went home.
> Today, I'll continue to look at these properties of alpha.
> because, yes, that's what's happening. one have alpha .5 and the
> other, 1.
> Answering Mike's question: the first system (the one I've wrote
> the code) is ubuntu 9.04, the other (with a newer version) is
> ubuntu server 8.04 LTS.Doesn't make any difference.
>
>
> On Thu, Oct 1, 2009 at 9:37 AM, Michael Droettboom
> <md...@st... <mailto:md...@st...>> wrote:
>
> Yeah, alpha handling is a bit of a mess -- it should probably
> be revamped in light of the fact that most places now accept
> rgba. We just need to decide if there is a good solution that
> doesn't break backward compatibility, or whether we should
> just break compatibility (e.g. remove set/get_alpha) moving
> forward.
>
> As for the current problem, I'll add a set_alpha call to the
> Shadow class.
>
> Mike
>
>
> Jae-Joon Lee wrote:
>
> Mike,
>
> I think this maybe related with some changes in how alpha
> is set (this
> happened sometime early this year I guess).
>
> I think the issue here is, when the shadow patch is
> created, it sets
> its facecolor with alpha=0.5., i.e., its _facecolor is
> something like
> (r, g, b, 0.5). But, shadow._alpha = 1 still. And later
> when the
> shadow is drawn, the alpha of the facecolor is simply
> overridden by
> _alpha. Given that alpha=0.5 is intended, I think this is
> a bug. But
> I'm not sure what is the preferred way to fix this.
>
> I think this is a general issue of Patch classes. While
> the alpha
> values can be set with facecolor and edgecolor, they are
> simply
> overridden by _alpha. If this behavior is necessary and
> intended, we
> should change the Shadow class to set its alpha correctly.
>
> I, personally, want to have different alphas for the
> facecolor and
> edgecolor, which cannot be done with the current approach.
> However, I
> believe the current backend api itself (draw_path) does
> not allow
> different alphas for edgecolor and facecolor, so it may
> best stick to
> the current behavior.
>
> Regards,
>
> -JJ
>
>
> On Wed, Sep 30, 2009 at 4:51 PM, Michael Droettboom
> <md...@st... <mailto:md...@st...>> wrote:
> 
>
> I'm still not seeing a difference between 0.98.5 and
> 0.99.1 here. I
> further investigation of the code shows that there
> were no changes in
> how the shadow color is computed between these
> versions. Is it possible
> you're using an even earlier version? You can
> determine it using:
>
> >>> import matplotlib
> >>> matplotlib.__version__
>
> Are there any other differences between the two
> installations, such as
> backend?
>
> Cheers,
> Mike
>
> Gewton Jhames wrote:
> 
>
> sorry, this is the script:
>
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
> from pylab import *
>
> from matplotlib.pyplot import figure, show
> from matplotlib.patches import Ellipse
> import numpy as np
>
> figure(1, figsize=(6,6), facecolor='#ffffff')
> ax = axes([0.1, 0.1, 0.8, 0.8])
>
> labels = 'label1', 'label2'
> fracs = [40, 60]
> colors = ['#E3AB9C', '#C6E9F8']
>
> explode=(0, 0.05)
>
> plots = pie(fracs, explode=explode, labels=labels,
> colors=colors,
> autopct='%0.2f%%', shadow=True)
> plots[0][0].set_edgecolor('#E4471A')
> plots[0][1].set_edgecolor('#1AA8E4')
> title('Raining Hogs and Dogs',
> bbox={'facecolor':'0.8', 'pad':5})
>
>
> show()
>
>
> On Wed, Sep 30, 2009 at 5:19 PM, Michael
> Droettboom <md...@st... <mailto:md...@st...>
> <mailto:md...@st... <mailto:md...@st...>>>
> wrote:
>
> Can you provide the script that produces these
> graphs? I don't
> see any difference between 0.98.5 and 0.99.1 on
> the included
> pie_demo.py example. Which backend are you using?
>
> Mike
>
> Gewton Jhames wrote:
>
> Hello, I'm having two different results in
> the shadow of a
> graph. I develop the graph in a system with
> matplotlib 0.98.5.
> When I put the code in other machine, with
> the same version of
> libpng, but with matplotlib 0.99.0, the
> shadow of the graph
> has changed to a real bad one.
>
> In attachment, the two generated graphs. I
> wish that the
> graph's shadown generated in 0.99 be the
> same of 0.98.5.
>
> Well, see the attachment and you'll understand.
> thanks.
>
> 
> ------------------------------------------------------------------------
>
>
> 
> ------------------------------------------------------------------------
>
> 
> ------------------------------------------------------------------------
>
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg;
> Developer Conference
> in SF, CA
> is the only developer event you need to
> attend this year.
> Jumpstart your
> developing skills, take BlackBerry mobile
> applications to
> market and stay ahead of the curve. Join us
> from November
> 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> 
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> 
> <mailto:Mat...@li...
> <mailto:Mat...@li...>>
> 
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
> 
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer
> Conference in SF, CA
> is the only developer event you need to attend this
> year. Jumpstart your
> developing skills, take BlackBerry mobile applications
> to market and stay
> ahead of the curve. Join us from November 9&#45;12,
> 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
> 
>
>
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

"solved".
In the system with the 0.99 version, in the file axes.py, class Axes, method
pie, the shadow is created:
 if shadow:
 # make sure to add a shadow after the call to
 # add_patch so the figure and transform props will be
 # set
 shad = mpatches.Shadow(w, -0.02, -0.02,
 )
 shad.set_zorder(0.9*w.get_zorder())
 self.add_patch(shad)
having a look at matplotlib.patches.Shadow we can see a bit of keyword
parameters. I passed this parameters when creating the Pie chart, and this
method send the parameters when creating the shadow (piece of code above).
So, I modifed the signature of the method pie and the line that creates a
shadow (*shad = mpatches.Shadow(w, -0.02 ...* ).
I put "solved" quoted because was not a very beautiful soluction, but, I
think was the best one for this case.
On Thu, Oct 1, 2009 at 10:13 AM, Gewton Jhames <gj...@gm...> wrote:
> OK, yesterday I was taking a look to the patch module. then, I went home.
> Today, I'll continue to look at these properties of alpha. because, yes,
> that's what's happening. one have alpha .5 and the other, 1.
> Answering Mike's question: the first system (the one I've wrote the code)
> is ubuntu 9.04, the other (with a newer version) is ubuntu server 8.04
> LTS.Doesn't make any difference.
>
>
> On Thu, Oct 1, 2009 at 9:37 AM, Michael Droettboom <md...@st...>wrote:
>
>> Yeah, alpha handling is a bit of a mess -- it should probably be revamped
>> in light of the fact that most places now accept rgba. We just need to
>> decide if there is a good solution that doesn't break backward
>> compatibility, or whether we should just break compatibility (e.g. remove
>> set/get_alpha) moving forward.
>>
>> As for the current problem, I'll add a set_alpha call to the Shadow class.
>>
>> Mike
>>
>>
>> Jae-Joon Lee wrote:
>>
>>> Mike,
>>>
>>> I think this maybe related with some changes in how alpha is set (this
>>> happened sometime early this year I guess).
>>>
>>> I think the issue here is, when the shadow patch is created, it sets
>>> its facecolor with alpha=0.5., i.e., its _facecolor is something like
>>> (r, g, b, 0.5). But, shadow._alpha = 1 still. And later when the
>>> shadow is drawn, the alpha of the facecolor is simply overridden by
>>> _alpha. Given that alpha=0.5 is intended, I think this is a bug. But
>>> I'm not sure what is the preferred way to fix this.
>>>
>>> I think this is a general issue of Patch classes. While the alpha
>>> values can be set with facecolor and edgecolor, they are simply
>>> overridden by _alpha. If this behavior is necessary and intended, we
>>> should change the Shadow class to set its alpha correctly.
>>>
>>> I, personally, want to have different alphas for the facecolor and
>>> edgecolor, which cannot be done with the current approach. However, I
>>> believe the current backend api itself (draw_path) does not allow
>>> different alphas for edgecolor and facecolor, so it may best stick to
>>> the current behavior.
>>>
>>> Regards,
>>>
>>> -JJ
>>>
>>>
>>> On Wed, Sep 30, 2009 at 4:51 PM, Michael Droettboom <md...@st...>
>>> wrote:
>>>
>>>
>>>> I'm still not seeing a difference between 0.98.5 and 0.99.1 here. I
>>>> further investigation of the code shows that there were no changes in
>>>> how the shadow color is computed between these versions. Is it possible
>>>> you're using an even earlier version? You can determine it using:
>>>>
>>>> >>> import matplotlib
>>>> >>> matplotlib.__version__
>>>>
>>>> Are there any other differences between the two installations, such as
>>>> backend?
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> Gewton Jhames wrote:
>>>>
>>>>
>>>>> sorry, this is the script:
>>>>>
>>>>> #!/usr/bin/python
>>>>> # -*- coding: utf-8 -*-
>>>>> from pylab import *
>>>>>
>>>>> from matplotlib.pyplot import figure, show
>>>>> from matplotlib.patches import Ellipse
>>>>> import numpy as np
>>>>>
>>>>> figure(1, figsize=(6,6), facecolor='#ffffff')
>>>>> ax = axes([0.1, 0.1, 0.8, 0.8])
>>>>>
>>>>> labels = 'label1', 'label2'
>>>>> fracs = [40, 60]
>>>>> colors = ['#E3AB9C', '#C6E9F8']
>>>>>
>>>>> explode=(0, 0.05)
>>>>>
>>>>> plots = pie(fracs, explode=explode, labels=labels, colors=colors,
>>>>> autopct='%0.2f%%', shadow=True)
>>>>> plots[0][0].set_edgecolor('#E4471A')
>>>>> plots[0][1].set_edgecolor('#1AA8E4')
>>>>> title('Raining Hogs and Dogs', bbox={'facecolor':'0.8', 'pad':5})
>>>>>
>>>>>
>>>>> show()
>>>>>
>>>>>
>>>>> On Wed, Sep 30, 2009 at 5:19 PM, Michael Droettboom <md...@st...
>>>>> <mailto:md...@st...>> wrote:
>>>>>
>>>>> Can you provide the script that produces these graphs? I don't
>>>>> see any difference between 0.98.5 and 0.99.1 on the included
>>>>> pie_demo.py example. Which backend are you using?
>>>>>
>>>>> Mike
>>>>>
>>>>> Gewton Jhames wrote:
>>>>>
>>>>> Hello, I'm having two different results in the shadow of a
>>>>> graph. I develop the graph in a system with matplotlib 0.98.5.
>>>>> When I put the code in other machine, with the same version of
>>>>> libpng, but with matplotlib 0.99.0, the shadow of the graph
>>>>> has changed to a real bad one.
>>>>>
>>>>> In attachment, the two generated graphs. I wish that the
>>>>> graph's shadown generated in 0.99 be the same of 0.98.5.
>>>>>
>>>>> Well, see the attachment and you'll understand.
>>>>> thanks.
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Come build with us! The BlackBerry&reg; Developer Conference
>>>>> in SF, CA
>>>>> is the only developer event you need to attend this year.
>>>>> Jumpstart your
>>>>> developing skills, take BlackBerry mobile applications to
>>>>> market and stay ahead of the curve. Join us from November
>>>>> 9&#45;12, 2009. Register now&#33;
>>>>> http://p.sf.net/sfu/devconf
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Matplotlib-users mailing list
>>>>> Mat...@li...
>>>>> <mailto:Mat...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Michael Droettboom
>>>>> Science Software Branch
>>>>> Operations and Engineering Division
>>>>> Space Telescope Science Institute
>>>>> Operated by AURA for NASA
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Operations and Engineering Division
>>>> Space Telescope Science Institute
>>>> Operated by AURA for NASA
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>>>> is the only developer event you need to attend this year. Jumpstart your
>>>> developing skills, take BlackBerry mobile applications to market and
>>>> stay
>>>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>>>> now&#33;
>>>> http://p.sf.net/sfu/devconf
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>>
>>>>
>>>
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>

Yeah, alpha handling is a bit of a mess -- it should probably be 
revamped in light of the fact that most places now accept rgba. We just 
need to decide if there is a good solution that doesn't break backward 
compatibility, or whether we should just break compatibility (e.g. 
remove set/get_alpha) moving forward.
As for the current problem, I'll add a set_alpha call to the Shadow class.
Mike
Jae-Joon Lee wrote:
> Mike,
>
> I think this maybe related with some changes in how alpha is set (this
> happened sometime early this year I guess).
>
> I think the issue here is, when the shadow patch is created, it sets
> its facecolor with alpha=0.5., i.e., its _facecolor is something like
> (r, g, b, 0.5). But, shadow._alpha = 1 still. And later when the
> shadow is drawn, the alpha of the facecolor is simply overridden by
> _alpha. Given that alpha=0.5 is intended, I think this is a bug. But
> I'm not sure what is the preferred way to fix this.
>
> I think this is a general issue of Patch classes. While the alpha
> values can be set with facecolor and edgecolor, they are simply
> overridden by _alpha. If this behavior is necessary and intended, we
> should change the Shadow class to set its alpha correctly.
>
> I, personally, want to have different alphas for the facecolor and
> edgecolor, which cannot be done with the current approach. However, I
> believe the current backend api itself (draw_path) does not allow
> different alphas for edgecolor and facecolor, so it may best stick to
> the current behavior.
>
> Regards,
>
> -JJ
>
>
> On Wed, Sep 30, 2009 at 4:51 PM, Michael Droettboom <md...@st...> wrote:
> 
>> I'm still not seeing a difference between 0.98.5 and 0.99.1 here. I
>> further investigation of the code shows that there were no changes in
>> how the shadow color is computed between these versions. Is it possible
>> you're using an even earlier version? You can determine it using:
>>
>> >>> import matplotlib
>> >>> matplotlib.__version__
>>
>> Are there any other differences between the two installations, such as
>> backend?
>>
>> Cheers,
>> Mike
>>
>> Gewton Jhames wrote:
>> 
>>> sorry, this is the script:
>>>
>>> #!/usr/bin/python
>>> # -*- coding: utf-8 -*-
>>> from pylab import *
>>>
>>> from matplotlib.pyplot import figure, show
>>> from matplotlib.patches import Ellipse
>>> import numpy as np
>>>
>>> figure(1, figsize=(6,6), facecolor='#ffffff')
>>> ax = axes([0.1, 0.1, 0.8, 0.8])
>>>
>>> labels = 'label1', 'label2'
>>> fracs = [40, 60]
>>> colors = ['#E3AB9C', '#C6E9F8']
>>>
>>> explode=(0, 0.05)
>>>
>>> plots = pie(fracs, explode=explode, labels=labels, colors=colors,
>>> autopct='%0.2f%%', shadow=True)
>>> plots[0][0].set_edgecolor('#E4471A')
>>> plots[0][1].set_edgecolor('#1AA8E4')
>>> title('Raining Hogs and Dogs', bbox={'facecolor':'0.8', 'pad':5})
>>>
>>>
>>> show()
>>>
>>>
>>> On Wed, Sep 30, 2009 at 5:19 PM, Michael Droettboom <md...@st...
>>> <mailto:md...@st...>> wrote:
>>>
>>> Can you provide the script that produces these graphs? I don't
>>> see any difference between 0.98.5 and 0.99.1 on the included
>>> pie_demo.py example. Which backend are you using?
>>>
>>> Mike
>>>
>>> Gewton Jhames wrote:
>>>
>>> Hello, I'm having two different results in the shadow of a
>>> graph. I develop the graph in a system with matplotlib 0.98.5.
>>> When I put the code in other machine, with the same version of
>>> libpng, but with matplotlib 0.99.0, the shadow of the graph
>>> has changed to a real bad one.
>>>
>>> In attachment, the two generated graphs. I wish that the
>>> graph's shadown generated in 0.99 be the same of 0.98.5.
>>>
>>> Well, see the attachment and you'll understand.
>>> thanks.
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry&reg; Developer Conference
>>> in SF, CA
>>> is the only developer event you need to attend this year.
>>> Jumpstart your
>>> developing skills, take BlackBerry mobile applications to
>>> market and stay ahead of the curve. Join us from November
>>> 9&#45;12, 2009. Register now&#33;
>>> http://p.sf.net/sfu/devconf
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> <mailto:Mat...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>> 
>> --
>> Michael Droettboom
>> Science Software Branch
>> Operations and Engineering Division
>> Space Telescope Science Institute
>> Operated by AURA for NASA
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Christopher Barrington-Leigh wrote:
>> This does not. First of all, "~" and "\mbox" are not supported if
>> usetex=False and I guess never will be. On the other hand,
>> as far as I can see, the whitespace stripping is not done in mpl
>> side. And I have a feeling that it may be the freetype library. mpl
>> uses FT_Glyph_Get_CBox to calculate the extents of the text and I
>> think this seems to fail when there is a trailing spaces. This is
>> beyond me I hope other developers have better idea.
>>
>>
>> 
>
> Thanks, I too hope some other developers chime in!
> 
>
The calculation of the text bounding box was only taking into account 
the outlines of the text -- and spaces don't have any outlines. I have 
updated this to also take into account the x-advance of each character, 
so it now works as expected. As this has the potential to break things, 
I did this on the trunk, not the maintenance branch, so it will make it 
into the next major release, not the next bugfix release.
The patch can be found here, if you wish to apply it locally:
http://matplotlib.svn.sourceforge.net/viewvc/matplotlib/trunk/matplotlib/src/ft2font.cpp?r1=7635&r2=7838
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

OK, yesterday I was taking a look to the patch module. then, I went home.
Today, I'll continue to look at these properties of alpha. because, yes,
that's what's happening. one have alpha .5 and the other, 1.
Answering Mike's question: the first system (the one I've wrote the code) is
ubuntu 9.04, the other (with a newer version) is ubuntu server 8.04
LTS.Doesn't make any difference.
On Thu, Oct 1, 2009 at 9:37 AM, Michael Droettboom <md...@st...> wrote:
> Yeah, alpha handling is a bit of a mess -- it should probably be revamped
> in light of the fact that most places now accept rgba. We just need to
> decide if there is a good solution that doesn't break backward
> compatibility, or whether we should just break compatibility (e.g. remove
> set/get_alpha) moving forward.
>
> As for the current problem, I'll add a set_alpha call to the Shadow class.
>
> Mike
>
>
> Jae-Joon Lee wrote:
>
>> Mike,
>>
>> I think this maybe related with some changes in how alpha is set (this
>> happened sometime early this year I guess).
>>
>> I think the issue here is, when the shadow patch is created, it sets
>> its facecolor with alpha=0.5., i.e., its _facecolor is something like
>> (r, g, b, 0.5). But, shadow._alpha = 1 still. And later when the
>> shadow is drawn, the alpha of the facecolor is simply overridden by
>> _alpha. Given that alpha=0.5 is intended, I think this is a bug. But
>> I'm not sure what is the preferred way to fix this.
>>
>> I think this is a general issue of Patch classes. While the alpha
>> values can be set with facecolor and edgecolor, they are simply
>> overridden by _alpha. If this behavior is necessary and intended, we
>> should change the Shadow class to set its alpha correctly.
>>
>> I, personally, want to have different alphas for the facecolor and
>> edgecolor, which cannot be done with the current approach. However, I
>> believe the current backend api itself (draw_path) does not allow
>> different alphas for edgecolor and facecolor, so it may best stick to
>> the current behavior.
>>
>> Regards,
>>
>> -JJ
>>
>>
>> On Wed, Sep 30, 2009 at 4:51 PM, Michael Droettboom <md...@st...>
>> wrote:
>>
>>
>>> I'm still not seeing a difference between 0.98.5 and 0.99.1 here. I
>>> further investigation of the code shows that there were no changes in
>>> how the shadow color is computed between these versions. Is it possible
>>> you're using an even earlier version? You can determine it using:
>>>
>>> >>> import matplotlib
>>> >>> matplotlib.__version__
>>>
>>> Are there any other differences between the two installations, such as
>>> backend?
>>>
>>> Cheers,
>>> Mike
>>>
>>> Gewton Jhames wrote:
>>>
>>>
>>>> sorry, this is the script:
>>>>
>>>> #!/usr/bin/python
>>>> # -*- coding: utf-8 -*-
>>>> from pylab import *
>>>>
>>>> from matplotlib.pyplot import figure, show
>>>> from matplotlib.patches import Ellipse
>>>> import numpy as np
>>>>
>>>> figure(1, figsize=(6,6), facecolor='#ffffff')
>>>> ax = axes([0.1, 0.1, 0.8, 0.8])
>>>>
>>>> labels = 'label1', 'label2'
>>>> fracs = [40, 60]
>>>> colors = ['#E3AB9C', '#C6E9F8']
>>>>
>>>> explode=(0, 0.05)
>>>>
>>>> plots = pie(fracs, explode=explode, labels=labels, colors=colors,
>>>> autopct='%0.2f%%', shadow=True)
>>>> plots[0][0].set_edgecolor('#E4471A')
>>>> plots[0][1].set_edgecolor('#1AA8E4')
>>>> title('Raining Hogs and Dogs', bbox={'facecolor':'0.8', 'pad':5})
>>>>
>>>>
>>>> show()
>>>>
>>>>
>>>> On Wed, Sep 30, 2009 at 5:19 PM, Michael Droettboom <md...@st...
>>>> <mailto:md...@st...>> wrote:
>>>>
>>>> Can you provide the script that produces these graphs? I don't
>>>> see any difference between 0.98.5 and 0.99.1 on the included
>>>> pie_demo.py example. Which backend are you using?
>>>>
>>>> Mike
>>>>
>>>> Gewton Jhames wrote:
>>>>
>>>> Hello, I'm having two different results in the shadow of a
>>>> graph. I develop the graph in a system with matplotlib 0.98.5.
>>>> When I put the code in other machine, with the same version of
>>>> libpng, but with matplotlib 0.99.0, the shadow of the graph
>>>> has changed to a real bad one.
>>>>
>>>> In attachment, the two generated graphs. I wish that the
>>>> graph's shadown generated in 0.99 be the same of 0.98.5.
>>>>
>>>> Well, see the attachment and you'll understand.
>>>> thanks.
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Come build with us! The BlackBerry&reg; Developer Conference
>>>> in SF, CA
>>>> is the only developer event you need to attend this year.
>>>> Jumpstart your
>>>> developing skills, take BlackBerry mobile applications to
>>>> market and stay ahead of the curve. Join us from November
>>>> 9&#45;12, 2009. Register now&#33;
>>>> http://p.sf.net/sfu/devconf
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> <mailto:Mat...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>>
>>>>
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Operations and Engineering Division
>>>> Space Telescope Science Institute
>>>> Operated by AURA for NASA
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>>> is the only developer event you need to attend this year. Jumpstart your
>>> developing skills, take BlackBerry mobile applications to market and stay
>>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>>> now&#33;
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>>
>>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>

Hello,
Printing in wx (with "printing_in_wx.py" from mpl examples) doesn't work 
on all pc (windows) I have tested.
A crash occur as described in the thread Printing in wx 
<http://sourceforge.net/mailarchive/message.php?msg_id=00de01c9dec9%240fed4310%241022a8c0%40ipkgatersleben.de> 
The only solution I found is to comment the line 2155 in backend_wx.py 
("self.canvas.figure.draw(renderer)")
The inconvenience is that the scale of the figure change on screen 
(during a short moment).
I hope it could help someone ...
Cédrick

Michael Droettboom wrote:
> You can use the twinx/twiny methods to join two axes after they've been
> created.
> 
> I don't think we currently provide a way to unjoin the subplots (either
> in the axes or in the Grouper class itself.) I think that's
> functionality we would need to add. If you can be so kind as to add a
> feature request to the tracker, it won't get lost.
It is done!
Thanks
Julien
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in '*9(9&(18%.\
9&1+,\'Z4(55l4('])"
"When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something is
impossible, he is very probably wrong." (first law of AC Clarke)

On Wed, Sep 30, 2009 at 4:38 PM, Christopher Barrington-Leigh
<cpb...@gm...> wrote:
>
>
> Jae-Joon Lee wrote:
>>
>> This works if you use recent version of matplotlib with preview mode
>> on. Without the preview mode (or other similar ways to report the
>> dimension of the text from TeX side), I don't think this can be done.
>>
>>
>
> Ok, thanks. I hope I am understanding. Would you be able to point me to a
> link to info on what you mean by "preview mode"?
> By recent version you mean something in the svn, I guess?
>
>
0.99.0 and later should work.
text.usetex : True
text.latex.preview : True
Include these in your rc file. While the preview.sty is installed in
most tex distribution, you may need to install it if not.
>
>
>> This does not. First of all, "~" and "\mbox" are not supported if
>> usetex=False and I guess never will be. On the other hand,
>> as far as I can see, the whitespace stripping is not done in mpl
>> side. And I have a feeling that it may be the freetype library. mpl
>> uses FT_Glyph_Get_CBox to calculate the extents of the text and I
>> think this seems to fail when there is a trailing spaces. This is
>> beyond me I hope other developers have better idea.
>>
>>
>
> Thanks, I too hope some other developers chime in!
>
>
>
>> So, Christopher,
>> I guess your best chance is to upgrade and use preview mode, or use
>> annotate function.
>>
>
> I am not clear how annotate helps. If I am willing to specify x,y locations,
> I can do that with text() as well, no?. It's still a matter of calculating
> how big a piece of whitespace should end up, roughly.
annotate let you specify offset from (x, y).
annotate("test", (1., 0.5), (-20, 0), xycoords='data',
 textcoords='offset points', ha="right")
Check the documentation.
Regards,
-JJ
>
> Thanks, JJ!
>
>
> --
> View this message in context: http://www.nabble.com/trailing-space-in-text-string-stripped%2C-making-it-impossible-to-right-pad-my-text-tp25639703p25688584.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Michael Droettboom wrote:
> David Cournapeau wrote:
>>
>> It ended up a confusion between the distutils build and the new scons
>> scripts I was working on, sorry for the noise.
>>
>> The good news is that matplotlib can now be built with numscons, with
>> all scons goodies :)
>> 
> Please share! :)
That's my intention, but github downtimes and anal firewall rules at my
university makes this challenging at the moment, unfortunately
David

Eric Firing wrote:
> jas...@cr... wrote:
>> A couple of us are trying to figure out how to scale arrows in a 
>> quiver plot so that we can exactly specify what the output arrows 
>> look like. For example, we'd like to scale the vectors to half of 
>> their size, and have it look like that on the quiver plot.
>>
>> So I tried even just getting a quiver plot to plot an arrow exactly 
>> as I passed it, without it scaling anything. My attempt is this:
>>
>> import matplotlib.pylab as plt
>> fig=plt.figure(figsize=[6,6])
>> q=plt.quiver([0],[0],[1],[1],units='x',scale=1,angles='xy')
>
> I have committed a change to svn trunk, so that if you change the
> above to
>
> q = plt.quiver([0],[0], [1], [1], scale_units='xy', angles='xy', scale=1)
>
> it should do exactly what you want. When scale_units is given, the 
> setting of "units" controls only the specification of the arrow width, 
> so if you are not specifying the width, it doesn't have any effect.
>
> If I could start from scratch, I probably could come up with a better 
> set of kwarg names and defaults; but for reasons of 
> backwards-compatibility, this is what we have. The new scale_units 
> kwarg makes it much easier to manually set the scale. Previously (and 
> still with the default of scale_units=None), it was almost hopelessly 
> confusing.
>
> (Maybe I should add "width_units", identical to "units", and deprecate 
> the latter; this might make the meanings of the kwargs clearer.)
>
Thanks!
Jason

jas...@cr... wrote:
> A couple of us are trying to figure out how to scale arrows in a quiver 
> plot so that we can exactly specify what the output arrows look like. 
> For example, we'd like to scale the vectors to half of their size, and 
> have it look like that on the quiver plot.
> 
> So I tried even just getting a quiver plot to plot an arrow exactly as I 
> passed it, without it scaling anything. My attempt is this:
> 
> import matplotlib.pylab as plt
> fig=plt.figure(figsize=[6,6])
> q=plt.quiver([0],[0],[1],[1],units='x',scale=1,angles='xy')
I have committed a change to svn trunk, so that if you change the
above to
q = plt.quiver([0],[0], [1], [1], scale_units='xy', angles='xy', scale=1)
it should do exactly what you want. When scale_units is given, the 
setting of "units" controls only the specification of the arrow width, 
so if you are not specifying the width, it doesn't have any effect.
If I could start from scratch, I probably could come up with a better 
set of kwarg names and defaults; but for reasons of 
backwards-compatibility, this is what we have. The new scale_units 
kwarg makes it much easier to manually set the scale. Previously (and 
still with the default of scale_units=None), it was almost hopelessly 
confusing.
(Maybe I should add "width_units", identical to "units", and deprecate 
the latter; this might make the meanings of the kwargs clearer.)
Eric
> ax=plt.axis([0,1.5,0,1.5])
> plt.grid(True)
> plt.savefig('test.png')
> 
> I'm trying to get the arrow to go from (0,0) to (1,1). However, with 
> units='x', it's just short, and with units='y', it's just a bit too 
> long. Furthermore, if I don't make the aspect ratio equal to one, I get 
> wild results since the x-axis and y-axis are different units then. It 
> would be really nice if there was a way to say units='data' (for data 
> coordinates), and then if scale=1, the arrows would be drawn with the 
> heads and tails at exactly the passed points. If scale=2, then each 
> arrow would be drawn exactly half of its length. I realize that 
> units='data' might mess up the other measurements of an arrow, though, 
> so maybe another parameter is called for, like a scale_units, that 
> defaults to units.
> 
> What do people think?
> 
> Thanks,
> 
> Jason
> 
> 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay 
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users