matplotlib-devel Mailing List for matplotlib (Page 4)

John Hunter wrote:
>> In tweaking mlab.psd(), I'm noticing there is a lot of overlap between
>> the keyword args for psd() and csd(). In fact, csd() doesn't document
>> them itself, but just references psd(). Additionally, the csd() and
>> psd() Axes methods duplicate these docs, with a few additional
>> parameters. Would it be a good thing to restructure the duplicated docs
>> into it's own string that can be incorporated when necessary? Or is
>> this kind of "monkey patching" of the docs something we're trying to
>> minimize?
> 
> No, this is something we are doing more of lately (eg see the contour
> docs) but the psd, csd, cohere predated this docstring manipulation.
> So feel free to consolidate.
I've done psd and csd so far. I might get to cohere (and spectrogram)
later. It got a little ugly doing the axes methods, since you can only
use a single dictionary for string replacement.
On a separate note, there is *A LOT* of code duplication between psd()
and csd() in mlab. It's bugged me while I've been doing these tweaks,
but the problem was that csd() would end up doing an extra FFT vs. the
same call to psd. I think I might finally have a solution:
1) Have psd(x) call csd(x,x)
2) Have csd() check if y is x, and if so, avoid doing the extra work.
Would this be an acceptable solution to reduce code duplication?
On a separate note, once I get done with these tweaks, are there any
objections to submitting something based on this to scipy?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Nov 11, 2008 at 10:35 AM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> In tweaking mlab.psd(), I'm noticing there is a lot of overlap between
> the keyword args for psd() and csd(). In fact, csd() doesn't document
> them itself, but just references psd(). Additionally, the csd() and
> psd() Axes methods duplicate these docs, with a few additional
> parameters. Would it be a good thing to restructure the duplicated docs
> into it's own string that can be incorporated when necessary? Or is
> this kind of "monkey patching" of the docs something we're trying to
> minimize?
No, this is something we are doing more of lately (eg see the contour
docs) but the psd, csd, cohere predated this docstring manipulation.
So feel free to consolidate.
JDH

Hi,
In tweaking mlab.psd(), I'm noticing there is a lot of overlap between
the keyword args for psd() and csd(). In fact, csd() doesn't document
them itself, but just references psd(). Additionally, the csd() and
psd() Axes methods duplicate these docs, with a few additional
parameters. Would it be a good thing to restructure the duplicated docs
into it's own string that can be incorporated when necessary? Or is
this kind of "monkey patching" of the docs something we're trying to
minimize?
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

ja...@be... schrieb:
> Dear all,
>
> after looking around for a plotting library I found Matplotlib and I tried to create a gray scale image in a wxpython application. Looks good!
>
> Now I have to find a line in the image with mainly vertical orientation. To do this a crosshair cursor would be fine. In Pylab I found a SpanSelector which also looks promising. 
>
> Unfortunately I failed in adding a crosshair cursor or a SpanSelector into my wxpython application figure.
>
> 
try
from matplotlib.widgets import Cursor
help(Cursor)
If this is not enough, I have once written a Crosshair very similar to 
SpanSelector - but I don't have it at hand at the moment.
Gregor

Eric Firing wrote:
> Ryan,
> 
> I hope you don't mind--I took care of the "FIXME" that I had put in, and
> committed the whole thing. Your test passes, and the backend_driver.py
> seems happy, so it should be OK.
You have stolen my glory! :) Actually, I was thinking at this point it
was more your patch anyways, and I had just done the work of tracking
down all the problem spots. Saves me the effort of doing the checkin. :)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> On Mon, Nov 10, 2008 at 5:54 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
> Ryan May wrote:
> 
> Ok, here's a patch that fixes the problem for me, as well as a test
> script that tests a bunch of the color options along with having
> more,
> the same, and less than the number of points passed in.
> 
> This is triggered by passing in a sequence of strings of the
> same length
> as x, which matplotlib interprets as needing colormapping.
> Colormapping
> an array of strings explodes nicely. I've fixed this issue by:
> 
> 1) Make scatter() check if c is a sequence of strings. If it
> is, use
> the colorConverter as expected.
> 
> 2) This requires changing is_string_like() to recognize elements
> from
> numpy string arrays (type numpy.string_) as strings. These
> elements are
> actually instances of a subclass of python strings
> (isinstance(<element>, str is True), but fail because they have
> a shape
> attribute (which is explicitly checked).
> 
> 3) Changing colorConverter.to_rgba_array() to accept a 1D numpy
> array
> containing strings. Currently, there is an explicit check for a 2D
> array, and if it is not, and exception is thrown.
> 
> Since this is my first mucking around in internals with which I
> am not
> familiar, I'd like someone to double check me. It's only a 3
> line diff,
> but each line is in a different file, so it's got a pretty wide
> (though
> thin) footprint.
> 
> 
> Ryan,
> 
> Here is a modification of your patch that I think will be very
> slightly more efficient and general.
> 
> 
> Thanks. That does look a lot more clean. It would have helped if I had 
> known about dtype.kind for ease of testing for arrays of strings and 
> numpy string scalars.
> 
> Anyone else?
Ryan,
I hope you don't mind--I took care of the "FIXME" that I had put in, and 
committed the whole thing. Your test passes, and the backend_driver.py 
seems happy, so it should be OK.
Eric
> 
> Ryan
> 
> --
> Ryan May
> Graduate Research Assistant
> School of Meteorology
> University of Oklahoma

On Mon, Nov 10, 2008 at 5:54 PM, Eric Firing <ef...@ha...> wrote:
> Ryan May wrote:
>
>> Ok, here's a patch that fixes the problem for me, as well as a test
>> script that tests a bunch of the color options along with having more,
>> the same, and less than the number of points passed in.
>>
>> This is triggered by passing in a sequence of strings of the same length
>> as x, which matplotlib interprets as needing colormapping. Colormapping
>> an array of strings explodes nicely. I've fixed this issue by:
>>
>> 1) Make scatter() check if c is a sequence of strings. If it is, use
>> the colorConverter as expected.
>>
>> 2) This requires changing is_string_like() to recognize elements from
>> numpy string arrays (type numpy.string_) as strings. These elements are
>> actually instances of a subclass of python strings
>> (isinstance(<element>, str is True), but fail because they have a shape
>> attribute (which is explicitly checked).
>>
>> 3) Changing colorConverter.to_rgba_array() to accept a 1D numpy array
>> containing strings. Currently, there is an explicit check for a 2D
>> array, and if it is not, and exception is thrown.
>>
>> Since this is my first mucking around in internals with which I am not
>> familiar, I'd like someone to double check me. It's only a 3 line diff,
>> but each line is in a different file, so it's got a pretty wide (though
>> thin) footprint.
>>
>
> Ryan,
>
> Here is a modification of your patch that I think will be very slightly
> more efficient and general.
>
Thanks. That does look a lot more clean. It would have helped if I had
known about dtype.kind for ease of testing for arrays of strings and numpy
string scalars.
Anyone else?
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Ubuntu 8.10 (Intrepid Ibex) I'm using matplotlib 0.98.3 and would
like to use the markerscale to make my legend points smaller (e.g.
0.6). However, it does not appear to be working. The following code:
plot(arange(0, 100, .1), cos(arange(0, 100, .1)), 'ro', markersize=20,
lable='test')
legend(markerscale=0.5)
draws a legend that has markers the same size as the original plot. I
saw someone posted on September 24, and had a response from someone.
For some reason, the response was blank (at least as it appears in the
list archives), so I thought I'd send another message to see if anyone
had figured out what needs to be done to get markerscale working?
Thanks
Orest

Ryan May wrote:
> Ryan May wrote:
>> Well, I can get the last one to work with SVN HEAD. The others don't
>> work for me either, though I agree they probably should.
>>
>> It looks like any 1D sequence will trigger colormapping instead of
>> strings being mapped to rgba arrays. I'll keep digging to see what
>> changed. (Unless someone beats me to it.)
> 
> Ok, here's a patch that fixes the problem for me, as well as a test
> script that tests a bunch of the color options along with having more,
> the same, and less than the number of points passed in.
> 
> This is triggered by passing in a sequence of strings of the same length
> as x, which matplotlib interprets as needing colormapping. Colormapping
> an array of strings explodes nicely. I've fixed this issue by:
> 
> 1) Make scatter() check if c is a sequence of strings. If it is, use
> the colorConverter as expected.
> 
> 2) This requires changing is_string_like() to recognize elements from
> numpy string arrays (type numpy.string_) as strings. These elements are
> actually instances of a subclass of python strings
> (isinstance(<element>, str is True), but fail because they have a shape
> attribute (which is explicitly checked).
> 
> 3) Changing colorConverter.to_rgba_array() to accept a 1D numpy array
> containing strings. Currently, there is an explicit check for a 2D
> array, and if it is not, and exception is thrown.
> 
> Since this is my first mucking around in internals with which I am not
> familiar, I'd like someone to double check me. It's only a 3 line diff,
> but each line is in a different file, so it's got a pretty wide (though
> thin) footprint.
Ryan,
Here is a modification of your patch that I think will be very slightly 
more efficient and general.
Eric
> 
> Ryan
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Version: matplotlib 0.98.3
I get no markers inside of the figure legend (using figlegend). Using "legend" shows the markers.
Try the following:
from pylab import *
lines = plot([1, 2, 3, 4], [2, 4, 7, 8], 'ro')
legend(lines, ["foo"])
figlegend(lines, ["foo"], "upper right")
show()
If I use 'r-' for the marker instead of 'ro', the figlegend() output matches the legend() output.
I believe this worked okay in version 0.82.
Great package. Thanks to the developers.
Rick
p.s. I did not file a bug on this. I would guess one may already exist, but a quick query of the mailing lists did not show anything that was obviously a similar posting.

Note that the weight argument was added to histogram in Numpy 1.1.
David
2008年10月29日 Olle Engdegård <ol...@fy...>
>
> Hi,
>
> I attach a trivial patch to pass a weight argument through hist() to
> histogram().
>
> Cheers,
> Olle
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

On Mon, Nov 10, 2008 at 1:59 PM, Ryan May <rm...@gm...> wrote:
>> I am not even sure if the above is the fix we want, but having numpy
>> string array elements fail "is_string_like" seems like a fundamentally
>> bad thing.
we definitely want numpy strings, eg in a record array, to return True here.

Ryan May wrote:
> Well, I can get the last one to work with SVN HEAD. The others don't
> work for me either, though I agree they probably should.
> 
> It looks like any 1D sequence will trigger colormapping instead of
> strings being mapped to rgba arrays. I'll keep digging to see what
> changed. (Unless someone beats me to it.)
Ok, here's a patch that fixes the problem for me, as well as a test
script that tests a bunch of the color options along with having more,
the same, and less than the number of points passed in.
This is triggered by passing in a sequence of strings of the same length
as x, which matplotlib interprets as needing colormapping. Colormapping
an array of strings explodes nicely. I've fixed this issue by:
1) Make scatter() check if c is a sequence of strings. If it is, use
the colorConverter as expected.
2) This requires changing is_string_like() to recognize elements from
numpy string arrays (type numpy.string_) as strings. These elements are
actually instances of a subclass of python strings
(isinstance(<element>, str is True), but fail because they have a shape
attribute (which is explicitly checked).
3) Changing colorConverter.to_rgba_array() to accept a 1D numpy array
containing strings. Currently, there is an explicit check for a 2D
array, and if it is not, and exception is thrown.
Since this is my first mucking around in internals with which I am not
familiar, I'd like someone to double check me. It's only a 3 line diff,
but each line is in a different file, so it's got a pretty wide (though
thin) footprint.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Well, I can get the last one to work with SVN HEAD. The others don't
> work for me either, though I agree they probably should.
> 
> It looks like any 1D sequence will trigger colormapping instead of
> strings being mapped to rgba arrays. I'll keep digging to see what
> changed. (Unless someone beats me to it.)
Ok, here's a patch that fixes the problem for me, as well as a test
script that tests a bunch of the color options along with having more,
the same, and less than the number of points passed in.
This is triggered by passing in a sequence of strings of the same length
as x, which matplotlib interprets as needing colormapping. Colormapping
an array of strings explodes nicely. I've fixed this issue by:
1) Make scatter() check if c is a sequence of strings. If it is, use
the colorConverter as expected.
2) This requires changing is_string_like() to recognize elements from
numpy string arrays (type numpy.string_) as strings. These elements are
actually instances of a subclass of python strings
(isinstance(<element>, str is True), but fail because they have a shape
attribute (which is explicitly checked).
3) Changing colorConverter.to_rgba_array() to accept a 1D numpy array
containing strings. Currently, there is an explicit check for a 2D
array, and if it is not, and exception is thrown.
Since this is my first mucking around in internals with which I am not
familiar, I'd like someone to double check me. It's only a 3 line diff,
but each line is in a different file, so it's got a pretty wide (though
thin) footprint.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Eric Firing wrote:
> The fix is:
> 
> def is_string_like(obj):
> """
> Return True if *obj* looks like a string
> 
> Such objects should include Python strings, unicode
> strings, and numpy string array scalars.
> """
> #if hasattr(obj, 'shape'): return 0
> # I think the above is a legacy of Numeric...
> try:
> if str(obj) + '' == obj:
> return True
> except (TypeError, ValueError):
> return False
> return True
> 
> I am not even sure if the above is the fix we want, but having numpy
> string array elements fail "is_string_like" seems like a fundamentally
> bad thing.
I agree. It's even more egregious when you consider that:
>>>s = numpy.string_('Foo')
>>>isinstance(s, str)
True
I think a nicer workaround at the moment might be to just see if the
passed in object *is* indeed a string instance, and if so, return True.
 I can't imagine that breaking anything. Figuring out why font
dictionary handling breaks would be good to do however.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Andrew Stock wrote:
> My interpretation of this is that either of the three values attempted
> in the code example should work. However, all of these fail.
> 
> from pylab import *
> 
> x = [1,2,3]
> y = [2,4,6]
> c = ['#ff0000', '#00ff00', '#0000ff']
> c = ['b','r', 'g']
> c = [(1,0,0), (0,1,0), (0,0,1)]
> 
> scatter(x, y, c=c)
> 
> show()
I'm working on a better fix right now, but can you try making sure you
have more (or less) colors specified than needed? I think that should
work around (or it seems to on SVN HEAD).
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:
> Eric Firing wrote:
>> ry...@us... wrote:
>>> Revision: 6385
>>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
>>> Author: ryanmay
>>> Date: 2008年11月10日 18:59:18 +0000 (2008年11月10日)
>>>
>>> Log Message:
>>> -----------
>>> Make iterable() and is_string_like() return True/False instead of 1/0.
>> Agreed--good cleanup.
>>
>> A larger problem is that if you index out an element from a numpy array 
>> of strings, it is a numpy string array scalar, and it is not recognized 
>> by is_string_like. I have a fix for that (not committed), but it 
>> causes breakage elsewhere. All this is an example of the perils of 
>> duck-typing; it has its advantages, but also its pitfalls.
> 
> What's your fix, and, more importantly, what breakage does it cause?
> I've added a fix locally to just check to see if the string is an
> instance of np.string_. It works, along with a few other things, to fix
> the scatter() problem. I was just getting ready to start running this
> stuff by the list...
The fix is:
def is_string_like(obj):
 """
 Return True if *obj* looks like a string
 Such objects should include Python strings, unicode
 strings, and numpy string array scalars.
 """
 #if hasattr(obj, 'shape'): return 0
 # I think the above is a legacy of Numeric...
 try:
 if str(obj) + '' == obj:
 return True
 except (TypeError, ValueError):
 return False
 return True
I am not even sure if the above is the fix we want, but having numpy 
string array elements fail "is_string_like" seems like a fundamentally 
bad thing.
Breakage is in font dictionary handling.
I don't have the whole problem solved, and I need to move on to other 
things right now.
Eric
> 
> Ryan
> 

Eric Firing wrote:
> ry...@us... wrote:
>> Revision: 6385
>> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
>> Author: ryanmay
>> Date: 2008年11月10日 18:59:18 +0000 (2008年11月10日)
>>
>> Log Message:
>> -----------
>> Make iterable() and is_string_like() return True/False instead of 1/0.
> 
> Agreed--good cleanup.
> 
> A larger problem is that if you index out an element from a numpy array 
> of strings, it is a numpy string array scalar, and it is not recognized 
> by is_string_like. I have a fix for that (not committed), but it 
> causes breakage elsewhere. All this is an example of the perils of 
> duck-typing; it has its advantages, but also its pitfalls.
What's your fix, and, more importantly, what breakage does it cause?
I've added a fix locally to just check to see if the string is an
instance of np.string_. It works, along with a few other things, to fix
the scatter() problem. I was just getting ready to start running this
stuff by the list...
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

ry...@us... wrote:
> Revision: 6385
> http://matplotlib.svn.sourceforge.net/matplotlib/?rev=6385&view=rev
> Author: ryanmay
> Date: 2008年11月10日 18:59:18 +0000 (2008年11月10日)
> 
> Log Message:
> -----------
> Make iterable() and is_string_like() return True/False instead of 1/0.
Agreed--good cleanup.
A larger problem is that if you index out an element from a numpy array 
of strings, it is a numpy string array scalar, and it is not recognized 
 by is_string_like. I have a fix for that (not committed), but it 
causes breakage elsewhere. All this is an example of the perils of 
duck-typing; it has its advantages, but also its pitfalls.
Eric
> 
> Modified Paths:
> --------------
> trunk/matplotlib/lib/matplotlib/cbook.py
> 
> Modified: trunk/matplotlib/lib/matplotlib/cbook.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/cbook.py	2008年11月09日 14:11:16 UTC (rev 6384)
> +++ trunk/matplotlib/lib/matplotlib/cbook.py	2008年11月10日 18:59:18 UTC (rev 6385)
> @@ -261,16 +261,16 @@
> def iterable(obj):
> 'return true if *obj* is iterable'
> try: len(obj)
> - except: return 0
> - return 1
> + except: return False
> + return True
> 
> 
> def is_string_like(obj):
> 'return true if *obj* looks like a string'
> - if hasattr(obj, 'shape'): return 0
> + if hasattr(obj, 'shape'): return False
> try: obj + ''
> - except (TypeError, ValueError): return 0
> - return 1
> + except (TypeError, ValueError): return False
> + return True
> 
> def is_sequence_of_strings(obj):
> """
> 
> 
> This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-checkins mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-checkins

Just a note -- my recent changes to the font cache were drastic enough 
that I changed the file name (a cheap form of versioning...). It is now 
fontList.cache -- I was hoping that would avoid this, but apparently 
not... :(
Mike
John Hunter wrote:
> On Sat, Nov 8, 2008 at 5:53 PM, Jae-Joon Lee <lee...@gm...> wrote:
> 
>> Yes, the script also works for me.
>> It seems that the version on the web is picking up a wrong font file.
>> 
>
> I flushed my font caches and rebuilt and the text is looking OK now.
> It may be that some combination of old font caches with Michael's
> recent changes to the font finder caused some grief, so everyone
> working from svn may want to flush the cache. Perhaps we should
> introduce version tagging on the caches, so these get flushed
> periodically on upgrades.
>
> I pushed the new docs up to the site - thanks for letting me know...
>
> Now I really better get back to the wife and kids :-)
>
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Andrew Stock wrote:
> My interpretation of this is that either of the three values attempted
> in the code example should work. However, all of these fail.
> 
> from pylab import *
> 
> x = [1,2,3]
> y = [2,4,6]
> c = ['#ff0000', '#00ff00', '#0000ff']
> c = ['b','r', 'g']
> c = [(1,0,0), (0,1,0), (0,0,1)]
> 
> scatter(x, y, c=c)
> 
> show()
> 
> If I change the call to scatter() to a call to bar() as so:
> 
> bar(x, y, color = c)
> 
> then each of the three examples work as I would expect.
> 
> Am I missing something in my interpretation of the documentation for
> scatter? Can anyone point out what I've missed?
Well, I can get the last one to work with SVN HEAD. The others don't
work for me either, though I agree they probably should.
It looks like any 1D sequence will trigger colormapping instead of
strings being mapped to rgba arrays. I'll keep digging to see what
changed. (Unless someone beats me to it.)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Hi,
I'm trying to specify the colours for markers in a call to scatter.
I've read this information in the documentation:
c:
 a color. c can be a single color format string, or a sequence of
color specifications of length N, or a sequence of N numbers to be
mapped to colors using the cmap and norm specified via kwargs (see
below). Note that c should not be a single numeric RGB or RGBA
sequence because that is indistinguishable from an array of values to
be colormapped. c can be a 2-D array in which the rows are RGB or
RGBA, however.
My interpretation of this is that either of the three values attempted
in the code example should work. However, all of these fail.
from pylab import *
x = [1,2,3]
y = [2,4,6]
c = ['#ff0000', '#00ff00', '#0000ff']
c = ['b','r', 'g']
c = [(1,0,0), (0,1,0), (0,0,1)]
scatter(x, y, c=c)
show()
If I change the call to scatter() to a call to bar() as so:
bar(x, y, color = c)
then each of the three examples work as I would expect.
Am I missing something in my interpretation of the documentation for
scatter? Can anyone point out what I've missed?
Thanks
Andrew

On Sat, Nov 8, 2008 at 5:53 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Yes, the script also works for me.
> It seems that the version on the web is picking up a wrong font file.
I flushed my font caches and rebuilt and the text is looking OK now.
It may be that some combination of old font caches with Michael's
recent changes to the font finder caused some grief, so everyone
working from svn may want to flush the cache. Perhaps we should
introduce version tagging on the caches, so these get flushed
periodically on upgrades.
I pushed the new docs up to the site - thanks for letting me know...
Now I really better get back to the wife and kids :-)
JDH

Yes, the script also works for me.
It seems that the version on the web is picking up a wrong font file.
-JJ
On Sat, Nov 8, 2008 at 6:28 PM, Eric Firing <ef...@ha...> wrote:
>
> John,
>
> Something really went haywire on this example:
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/logo.html
>
> It works on my machine, so I don't know why the version on the web site
> is wrong.
>
> Eric
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

John,
Something really went haywire on this example:
http://matplotlib.sourceforge.net/examples/pylab_examples/logo.html
It works on my machine, so I don't know why the version on the web site 
is wrong.
Eric