matplotlib-devel Mailing List for matplotlib (Page 4)

mpl hates my guts today.
I'm developing an application for work and need to plot some spectra on a 
logscale. I can recreate my problem with embedding_in_qt4, by replacing 
MyDynamicMplCanvas.compute_initial_figure with this:
 def compute_initial_figure(self):
 self.axes.plot([0, 1, 2, 3], [1, 2, 0, 4], 'r')
 self.axes.set_yscale('log')
[...] 
File "/usr/lib64/python2.5/site-packages/matplotlib-0.90.1_r3709-py2.5-linux-x86_64.egg/matplotlib/axes.py", 
line 1664, in set_ylim
 raise ValueError('Cannot set nonpositive limits with log transform')
ValueError: Cannot set nonpositive limits with log transform
I get that error even if I modify the update figure function so there is no 
possibility of zeros occuring in the data:
 def update_figure(self):
 # Build a list of 4 random integers between 0 and 10 (both inclusive)
 l = [ random.randint(0, 10) for i in xrange(4) ]
 l[l<=0]=1 # I love numpy
 self.axes.plot([1, 1, 2, 3], l, 'r')
 self.draw()
Anyone have any ideas? I think I have a bad case of gremlins.
Darren

Rob, Mike,
What this implies to me is that either there is a problem with the code 
that is generating afmdict (and I did not change that code, I just 
caused it to be invoked when the fontManager instance is created.), or 
there is a problem with some .afm files on Rob's machine.
I really don't know how to troubleshoot it beyond this.
(As a separate issue, I probably I should change font_manager.py so that 
if the rcParams value below was changed since the cache was made, it 
will be rebuilt with the new value.)
Eric
Rob Hetland wrote:
> On Aug 14, 2007, at 1:55 PM, Eric Firing wrote:
> 
>> rcParams['pdf.use14corefonts']
> 
> Indeed, reversing this value fixes the problem.
> 
> My value had been set to False.
> 	pdf.use14corefonts : True
> in the mplrc file works with the latest revision.
> 
> -r
> 
> ----
> Rob Hetland, Associate Professor
> Dept. of Oceanography, Texas A&M University
> http://pong.tamu.edu/~rob
> phone: 979-458-0096, fax: 979-845-6331
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Aug 14, 2007, at 1:55 PM, Eric Firing wrote:
> rcParams['pdf.use14corefonts']
Indeed, reversing this value fixes the problem.
My value had been set to False.
	pdf.use14corefonts : True
in the mplrc file works with the latest revision.
-r
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Mike, Rob,
One of the changes I made was to cause the afmdict to be generated 
automatically at the start rather than on demand. The problem you are 
having seems related to afm fonts, so I suspect this is it.
What is your rcParams['pdf.use14corefonts'] setting? Please try 
reversing it, and see if that changes the result. This is looking for a 
clue, not a solution.
(I knew I should have left the font stuff alone...)
Thanks.
Eric
Michael Droettboom wrote:
> Hmm... I'm not readily able to reproduce this here.
> 
> What are you setting in matplotlibrc (or in your plot?)
> 
> Also, if you delete the font cache (which is now 
> ~/.matplotlib/fontManager.cache), does that help? (Might be a useful 
> data point -- not suggesting it as a solution.)
> 
> Cheers,
> Mike
> 
> Rob Hetland wrote:
>>> Done and committed.
>>
>> It seems a recent commit has severely broken my font loading. When I 
>> start MPL now, I get an infinite stream of messages similar to:
>>
>> Found an unknown keyword in AFM header (was )
>> Found an unknown keyword in AFM header (was !"% 
>> #&#2*3*9*:*<=@ADE*@";;"C#C)*=>A&B879(') 
>> **7'6'7#5#3#327#"'#5##53&'#7/75&'7535#35#35#'3'#' )
>> Found an unknown keyword in AFM header (was ?)52
>>
>> Je)
>> !_)nd an unknown keyword in AFM header (wasSSJJJJ.,?+%"5??0
>> Found an unknown keyword in AFM header (was
>> g
>>
>>
>> Perhaps this is related to the recent commit?
>>
>> -r
>>
>> ----
>> Rob Hetland, Associate Professor
>> Dept. of Oceanography, Texas A&M University
>> http://pong.tamu.edu/~rob
>> phone: 979-458-0096, fax: 979-845-6331
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

> What are you setting in matplotlibrc (or in your plot?)
>
> Also, if you delete the font cache (which is now
> ~/.matplotlib/fontManager.cache), does that help? (Might be a useful
> data point -- not suggesting it as a solution.)
Well, I've been trying out the Arev fonts, as you know, so I changed 
those back to Bitstream Vera Sans. I deleted the cache. I took out 
the mathtext stuff. All that is left is pretty vanilla rc.
Perhaps it's a Mac thing?
Also, revision 3700 works, so that can at least frame the initiation 
of the bug. I can whittle this down to the exact revision (there are 
only nine since 3700), if that is needed,
-r
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

Hmm... I'm not readily able to reproduce this here.
What are you setting in matplotlibrc (or in your plot?)
Also, if you delete the font cache (which is now 
~/.matplotlib/fontManager.cache), does that help? (Might be a useful 
data point -- not suggesting it as a solution.)
Cheers,
Mike
Rob Hetland wrote:
>> Done and committed.
> 
> It seems a recent commit has severely broken my font loading. When I 
> start MPL now, I get an infinite stream of messages similar to:
> 
> Found an unknown keyword in AFM header (was )
> Found an unknown keyword in AFM header (was !"% 
> #&#2*3*9*:*<=@ADE*@";;"C#C)*=>A&B879(') 
> **7'6'7#5#3#327#"'#5##53&'#7/75&'7535#35#35#'3'#' )
> Found an unknown keyword in AFM header (was ?)52
> 
> Je)
> !_)nd an unknown keyword in AFM header (wasSSJJJJ.,?+%"5??0
> Found an unknown keyword in AFM header (was
> g
> 
> 
> Perhaps this is related to the recent commit?
> 
> -r
> 
> ----
> Rob Hetland, Associate Professor
> Dept. of Oceanography, Texas A&M University
> http://pong.tamu.edu/~rob
> phone: 979-458-0096, fax: 979-845-6331
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

> Done and committed.
It seems a recent commit has severely broken my font loading. When I 
start MPL now, I get an infinite stream of messages similar to:
Found an unknown keyword in AFM header (was )
Found an unknown keyword in AFM header (was !"% 
#&#2*3*9*:*<=@ADE*@";;"C#C)*=>A&B879(') 
**7'6'7#5#3#327#"'#5##53&'#7/75&'7535#35#35#'3'#' )
Found an unknown keyword in AFM header (was ?)52
 Je)
!_)nd an unknown keyword in AFM header (wasSSJJJJ.,?+%"5??0
Found an unknown keyword in AFM header (was
 g
Perhaps this is related to the recent commit?
-r
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

At 10:36 AM 8/14/2007, Eric Firing wrote:
>Ted Drain wrote:
>>Manuel,
>>We do plots like this all the time. One thing we've found that's 
>>nice to have is a keyword that controls when the increase in y 
>>happens. We use a step style keyword that can be 'pre' (go up then 
>>right), 'post' (go right then up), and 'mid' (right 0.5, up, right 0.5).
>Good idea.
>>Regarding your patch, you might want to check other areas in MPL 
>>for data processing examples. I could be wrong but I'm not sure 
>>you can assume that incoming data is a float. Some of the unit 
>>conversion examples or the line collection code might have better examples.
>
>Incoming data can be any numeric type, but it ends up getting 
>converted to the default float type (not float32) internally.
>
>Whenever possible, it is good to support masked array input.
Agreed - but the way the patch was written, I don't think it will 
support anything but float (especially not the unit types).
>Eric
>>Ted
>>At 07:59 AM 8/14/2007, Manuel Metz wrote:
>>>Hi,
>>>
>>>I have created a patch against latest svn that adds a function 
>>>step to the axes class to plot step-functions ;-) It's really 
>>>simple but nice ... Any interest in adding this?
>>>
>>>Manuel
>>>
>>>
>>>
>>>
>>>Index: axes.py
>>>===================================================================
>>>--- axes.py (revision 3709)
>>>+++ axes.py (working copy)
>>>@@ -4995,6 +4995,18 @@
>>> steps=[1, 2, 5, 10],
>>> integer=True))
>>> return im
>>>+
>>>+ def step(self, x, y, *args, **kwargs):
>>>+ x2 = npy.zeros((2*len(x)), npy.float32)
>>>+ y2 = npy.zeros((2*len(x)), npy.float32)
>>>+
>>>+ x2[0::2] = x
>>>+ x2[1::2] = x
>>>+
>>>+ y2[1::2] = y
>>>+ y2[2::2] = y[:-1]
>>>+
>>>+ self.plot(x2, y2, *args, **kwargs)
>>>
>>> class SubplotBase:
>>> """
>>>
>>>-------------------------------------------------------------------------
>>>This SF.net email is sponsored by: Splunk Inc.
>>>Still grepping through log files to find problems? Stop.
>>>Now Search log events and configuration files using AJAX and a browser.
>>>Download your FREE copy of Splunk now >> http://get.splunk.com/
>>>_______________________________________________
>>>Matplotlib-devel mailing list
>>>Mat...@li...
>>>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>------------------------------------------------------------------------
>>-------------------------------------------------------------------------
>>This SF.net email is sponsored by: Splunk Inc.
>>Still grepping through log files to find problems? Stop.
>>Now Search log events and configuration files using AJAX and a browser.
>>Download your FREE copy of Splunk now >> http://get.splunk.com/
>>
>>------------------------------------------------------------------------
>>_______________________________________________
>>Matplotlib-devel mailing list
>>Mat...@li...
>>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Ted Drain wrote:
> Manuel,
> We do plots like this all the time. One thing we've found that's nice 
> to have is a keyword that controls when the increase in y happens. We 
> use a step style keyword that can be 'pre' (go up then right), 'post' 
> (go right then up), and 'mid' (right 0.5, up, right 0.5). 
Good idea.
> 
> Regarding your patch, you might want to check other areas in MPL for 
> data processing examples. I could be wrong but I'm not sure you can 
> assume that incoming data is a float. Some of the unit conversion 
> examples or the line collection code might have better examples.
Incoming data can be any numeric type, but it ends up getting converted 
to the default float type (not float32) internally.
Whenever possible, it is good to support masked array input.
Eric
> 
> Ted
> 
> At 07:59 AM 8/14/2007, Manuel Metz wrote:
>> Hi,
>>
>> I have created a patch against latest svn that adds a function step to 
>> the axes class to plot step-functions ;-) It's really simple but nice 
>> ... Any interest in adding this?
>>
>> Manuel
>>
>>
>>
>>
>> Index: axes.py
>> ===================================================================
>> --- axes.py (revision 3709)
>> +++ axes.py (working copy)
>> @@ -4995,6 +4995,18 @@
>> steps=[1, 2, 5, 10],
>> integer=True))
>> return im
>> + 
>> + def step(self, x, y, *args, **kwargs):
>> + x2 = npy.zeros((2*len(x)), npy.float32)
>> + y2 = npy.zeros((2*len(x)), npy.float32)
>> + 
>> + x2[0::2] = x
>> + x2[1::2] = x
>> + 
>> + y2[1::2] = y
>> + y2[2::2] = y[:-1]
>> + 
>> + self.plot(x2, y2, *args, **kwargs)
>> 
>> class SubplotBase:
>> """
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc.
>> Still grepping through log files to find problems? Stop.
>> Now Search log events and configuration files using AJAX and a browser.
>> Download your FREE copy of Splunk now >> http://get.splunk.com/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Manuel,
We do plots like this all the time. One thing we've found that's 
nice to have is a keyword that controls when the increase in y 
happens. We use a step style keyword that can be 'pre' (go up then 
right), 'post' (go right then up), and 'mid' (right 0.5, up, right 0.5).
Regarding your patch, you might want to check other areas in MPL for 
data processing examples. I could be wrong but I'm not sure you can 
assume that incoming data is a float. Some of the unit conversion 
examples or the line collection code might have better examples.
Ted
At 07:59 AM 8/14/2007, Manuel Metz wrote:
>Hi,
>
>I have created a patch against latest svn that adds a function step 
>to the axes class to plot step-functions ;-) It's really simple but 
>nice ... Any interest in adding this?
>
>Manuel
>
>
>
>
>Index: axes.py
>===================================================================
>--- axes.py (revision 3709)
>+++ axes.py (working copy)
>@@ -4995,6 +4995,18 @@
> steps=[1, 2, 5, 10],
> integer=True))
> return im
>+
>+ def step(self, x, y, *args, **kwargs):
>+ x2 = npy.zeros((2*len(x)), npy.float32)
>+ y2 = npy.zeros((2*len(x)), npy.float32)
>+
>+ x2[0::2] = x
>+ x2[1::2] = x
>+
>+ y2[1::2] = y
>+ y2[2::2] = y[:-1]
>+
>+ self.plot(x2, y2, *args, **kwargs)
>
> class SubplotBase:
> """
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems? Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> http://get.splunk.com/
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Thu, Aug 02, 2007 at 10:31:04AM -0400, Michael Droettboom wrote:
> I don't know if we ever reached consensus on how to specify math text 
> vs. regular text. I agree with Eric that it's down to two options: 
> using a new kw argument (probably format="math" to be most future-proof) 
> or Math('string'). I don't think I have enough "historical perspective" 
> to really make the call but I do have a concern about the second option 
> that it may be confusing depending on how "Math" is imported. (It may 
> have to be pylab.Math in some instances but not in others.) But I don't 
> have a strong objection.
> 
> Any last objections to going with the new keyword argument?
I'm guessing that this discussion is already closed, but I would still
like to propose another option, just like the original: specify the
format in the string itself by requiring a leading '$'. 
For example:
 text(x, y, r'$\sin(x)$')
or for those functions not starting with math:
 text(x, y, r'$$phase $[0,2\pi)$')
This is a variant on Math(r'$\sin(x)$') which is a bit more compact.
As has been pointed out elsewhere, whether or not the string contains
tex markup is a property of the string, not a property of the function
that use the string. Note that the format keyword will be required for 
all functions which have string inputs, and may cause problems if there 
are multiple string inputs to the function. legend() in particular may 
be a problem.
	- Paul

Hi,
I have created a patch against latest svn that adds a function step to 
the axes class to plot step-functions ;-) It's really simple but nice 
... Any interest in adding this?
Manuel

Michael Droettboom wrote:
> My suspicion from looking at the code was that a great deal of time
was spent statting all the font files at start up. FontManager.__init__
goes through all the files in the cache to determine if they still exist
and refreshes the cache if it finds one missing. Your patch (if I
understand pickling correctly) is bypassing all those checks, which I
think is generally a good thing.
> 
> However, now findfont has the potential to return a path to a file
that no longer exists. findfont should probably be wrapped in a function
that will check the result, and if the path doesn't exist, rebuild the
cache and then perform the query again.
Done and committed.
Eric
> Cheers,
> Mike

Michael Droettboom wrote:
> Just wanted to link up this thread with a question I posed on the cairo 
> mailing list.
> 
> http://lists.cairographics.org/archives/cairo/2007-August/011201.html
> 
> Cheers,
> Mike
> 
> Eric Firing wrote:
>> Michael Droettboom wrote:
>> [...]
>>> One middle ground I thought of since my first message is to use 
>>> fc-list to get a list of all the fonts on the system, and continue to 
>>> use font_manager.py for the font matching. If "fc-list" is not 
>>> available, it could fall back to the hard-coded paths it uses now. 
>>> Of course, the matching in font_manager.py would still need to be 
>>> improved.
>>
>> Sounds reasonable.
Your change to use fontconfig slightly raised the time for 
backend_driver.py Template: 0.50 -> 0.53 minutes.
>>
>> While you are poking around in font_manager: this is one of the 
>> biggest chunks of mpl script startup time, even with the present 
>> caching. I haven't looked very closely or done any testing, but I 
>> suspect more extensive caching could work fine. Specifically, can the 
>> entire fontManager instance be pickled, and loaded if it exists?
I tried this (svn diff is attached), and it cut the time above to 0.43 
minutes. I have not committed it; I very much like doing what we can to 
reduce startup time (which is important for applications that run simple 
plots as standalone scripts), but perhaps the approach here will cause 
too much trouble, or will require better error trapping downstream to 
handle the case where the fontManager actually needs to be rebuilt.
Eric
>>
>> Eric
>>
>>> Cheers,
>>> Mike
>>
> 

On Aug 13, 2007, at 10:37 AM, Michael Droettboom wrote:
> mathtext.use_cm : False
> mathtext.fallback_to_cm : True
> mathtext.cal : (['Arev Sans'], 'normal', 'oblique')
> mathtext.it : (['Arev Sans'], 'normal', 'oblique')
> mathtext.rm : (['Arev Sans'], 'normal', 'normal')
> mathtext.bf : (['Arev Sans'], 'bold', 'normal')
> mathtext.sf : (['Arev Sans'], 'normal', 'normal')
I've got this set, but I still get an error message like:
 >>> text(5, 0.8, r'$\beta$', fontsize=20)
/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- 
packages/matplotlib/mathtext.py:732: MathTextWarning: Font 
'BitstreamVeraSans-Roman' does not have a glyph for '\beta'
 MathTextWarning)
<matplotlib.text.Text instance at 0x18dfedf0>
I know that Arev has all of the greek letters, but MPL does not seem 
to be able to use these. The sans-serif font should also be Arev 
Sans (according to rcParams), so I'm not sure where it it picking up 
bitstream-vera (unless Arev still calls itself that).
-Rob
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Aug 13, 2007, at 10:37 AM, Michael Droettboom wrote:
> I put all the Arev fonts in my
> ~/.fonts (which is now looked at by matplotlib)
FontBook (a Mac font manager) put user installed fonts into ~/Library/ 
Fonts by default. Perhaps this would also be a good place for MPL to 
look for fonts.
-r
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

On Monday 13 August 2007 01:53:40 pm David Huard wrote:
> Hi,
>
> I noticed a strange behavior and I'm not sure whether it is intended or
> not.
>
>
> With the usetex option set to True, the fonts used in ticklabels change
> when using a custom formatter. So for instance
>
> from pylab import *
> rcParams['text.usetex']=True
> s = subplot(111)
> s.xaxis.set_major_formatter(FormatStrFormatter('%3.2f'))
> savefig('test')
>
> the figure has different fonts in the x and y axes.
>
> HTH and thanks for all the work you put in matplotlib, it's much
> appreciated.
The fonts look the same to me for both axes. Maybe try deleting your 
~/.matplotlibrc/tex.cache?
Darren

Hi,
I noticed a strange behavior and I'm not sure whether it is intended or not.
With the usetex option set to True, the fonts used in ticklabels change when
using a custom formatter. So for instance
from pylab import *
rcParams['text.usetex']=True
s = subplot(111)
s.xaxis.set_major_formatter(FormatStrFormatter('%3.2f'))
savefig('test')
the figure has different fonts in the x and y axes.
HTH and thanks for all the work you put in matplotlib, it's much
appreciated.
David

Michael Droettboom wrote:
> Rob Hetland wrote:
>> On Aug 6, 2007, at 4:03 PM, Michael Droettboom wrote:
>> I have been thinking that it might be possible to use some of the CM 
>> sans fonts, like CM bright. Also, there is a Arev font set (vera, 
>> backwards -- basically Bitstream Vera with math extensions) that looks 
>> like it might be promising, but it seems that mathtext does not see 
>> these extented characters.
> 
> I'll download these fonts and give them a try.
The Arev fonts are working for me. They aren't 100% complete, but there 
are lots of basic things in there, like \neq for instance. In fact, 
this is the most complete free font I've seen in terms of math symbols 
(The long-awaited Stix fonts don't count until I can see it). There are 
also symbols in there which are not part of regular LaTeX, and at 
present there is no way to get at them from matplotlib. (That's on my 
TODO list.)
Perhaps it's a configuration issue? I put all the Arev fonts in my 
~/.fonts (which is now looked at by matplotlib) and added the following 
to my matplotlibrc:
mathtext.use_cm : False
mathtext.fallback_to_cm : True
mathtext.cal : (['Arev Sans'], 'normal', 'oblique')
mathtext.it : (['Arev Sans'], 'normal', 'oblique')
mathtext.rm : (['Arev Sans'], 'normal', 'normal')
mathtext.bf : (['Arev Sans'], 'bold', 'normal')
mathtext.sf : (['Arev Sans'], 'normal', 'normal')
Cheers,
Mike

Rob Hetland wrote:
> 
> On Aug 6, 2007, at 4:03 PM, Michael Droettboom wrote:
>> There is now experimental support for custom fonts in math mode.
>> Try the above, and let me know how it goes...
> 
> I finally had time to try out your new code a bit, and I like it. It 
> works well for the very simple cases, like superscripts. One thing that 
> I noticed is that the height of the superscript depends on the font size 
> -- is this a hardwired distance, or relative to font size.
It is intended to be relative to the xheight (the height of a lower case 
x) in the font. If you find any cases where it looks really wrong, let 
me know. I don't know how reliable the xheight information in the font is.
> Also, it 
> seems that when using the regular unicode fonts, more difficult math 
> expressions, e.g., integrals, look terrible. I guess this is the point 
> when CM is unavoidable...
I agree, they look terrible. There are things that could be done -- 
like using CM for only certain characters, such as the radical -- but 
that sort of depends on what font you're using for the rest of the math. 
 It may be that the user provides a font that *does* have a good 
integral. None of that is very difficult to do, but finding a way to 
expose it to the user without exposing too much complexity and causing 
too many different testing configurations is the hard part. I think the 
end result may be a very small set of "font configurations" that work 
reasonably well, and anything outside of that is sort of "unsupported" 
territory.
> I have been thinking that it might be possible to use some of the CM 
> sans fonts, like CM bright. Also, there is a Arev font set (vera, 
> backwards -- basically Bitstream Vera with math extensions) that looks 
> like it might be promising, but it seems that mathtext does not see 
> these extented characters.
I'll download these fonts and give them a try.
> I found an excellent writeup on math/text font combinations in LaTeX here:
> http://ctan.tug.org/tex-archive/info/Free_Math_Font_Survey/survey.html
> from this informative page:
> http://cg.scs.carleton.ca/~luc/greek.html
> There are, of course, many others.
Thanks for those links. That certainly provides a lot of options... 
I'll have to look into these further.
Cheers,
Mike

Rob Hetland wrote:
> 
> On Aug 6, 2007, at 4:03 PM, Michael Droettboom wrote:
>> There is now experimental support for custom fonts in math mode.
>> Try the above, and let me know how it goes...
> 
> I finally had time to try out your new code a bit, and I like it. It 
> works well for the very simple cases, like superscripts. One thing that 
> I noticed is that the height of the superscript depends on the font size 
> -- is this a hardwired distance, or relative to font size.
It is intended to be relative to the xheight (the height of a lower case 
x) in the font. If you find any cases where it looks really wrong, let 
me know. I don't know how reliable the xheight information in the font is.
> Also, it 
> seems that when using the regular unicode fonts, more difficult math 
> expressions, e.g., integrals, look terrible. I guess this is the point 
> when CM is unavoidable...
I agree, they look terrible. There are things that could be done -- 
like using CM for only certain characters -- but that sort of depends on 
what font you're using for the rest of the math. It may be that the 
user provides a font that *does* have a good integral. None of that is 
very difficult to do, but finding a way to expose it to the user without 
exposing too much complexity and causing too many different testing 
configurations is the hard part. I think the end result may be a very 
small set of "font configurations" that work reasonably well, and 
anything outside of that is sort of "unsupported" territory.
> I have been thinking that it might be possible to use some of the CM 
> sans fonts, like CM bright. Also, there is a Arev font set (vera, 
> backwards -- basically Bitstream Vera with math extensions) that looks 
> like it might be promising, but it seems that mathtext does not see 
> these extented characters.
I'll download these fonts and give them a try.
> I found an excellent writeup on math/text font combinations in LaTeX here:
> http://ctan.tug.org/tex-archive/info/Free_Math_Font_Survey/survey.html
> from this informative page:
> http://cg.scs.carleton.ca/~luc/greek.html
> There are, of course, many others.
Thanks for those links. That certainly provides a lot of options... 
I'll have to look into these further.
Cheers,
Mike

Quick status update --
I've committed code to font_manager that will retrieve the list of all 
installed fonts from fontconfig if available (using making a shell call 
to fc-list). This will handle the cases where users want to use fonts 
that have been installed in non-standard places or their distributions 
do something different.
I've decided to put off making other improvements to font_manager for 
the time being. I'm somewhat torn between adding a dependency on 
fontconfig and having all those issues taken care of by others, or 
adding incremental fixes to font_manager, but maintaining easy 
Python-level portability.
A new thing that makes fontconfig particularly compelling is looking up 
fonts based on the character sets they contain. This would be very 
useful for mathtext when using non-Computer Modern (Bakoma) fonts, for 
instance. It could all be done without fontconfig, of course, but it 
would be reinventing a rather large wheel.
My original impetus to support fontconfig, to help the Cairo backend 
behave more like our other backends, is less important, IMHO. It seems 
unlikely, from my response on the cairo mailing list, that pycairo will 
grow an API to load fonts directly from a file.
Some more information --
- I've successfully built it on Mac and Windows (with Mingw32) and it 
seems to be doing the right things there, without any post-install 
configuration work.
- The API allows applications to add their own font directories on the 
fly, so everything could continue work the way it does now (by looking 
in the mpl-data directory for fonts).
- The Python wrappers for the parts we need would be quite minimal. 
(Probably only two functions FcFontMatch and FcConfigAppFontAddDir.)
- fontconfig depends on expat for XML reading.
- It appears that both the fontconfig and expat licenses would permit us 
to distribute them with matplotlib if we chose to. We would probably 
only want to use the embedded versions when the OS doesn't provide it 
(OS-X and Windows).
In any case, I'm just putting this on the table. It's always hard to 
weigh those tradeoffs.
Cheers,
Mike
Michael Droettboom wrote:
> Just wanted to link up this thread with a question I posed on the cairo 
> mailing list.
> 
> http://lists.cairographics.org/archives/cairo/2007-August/011201.html
> 
> Cheers,
> Mike
> 
> Eric Firing wrote:
>> Michael Droettboom wrote:
>> [...]
>>> One middle ground I thought of since my first message is to use 
>>> fc-list to get a list of all the fonts on the system, and continue to 
>>> use font_manager.py for the font matching. If "fc-list" is not 
>>> available, it could fall back to the hard-coded paths it uses now. Of 
>>> course, the matching in font_manager.py would still need to be improved.
>> Sounds reasonable.
>>
>> While you are poking around in font_manager: this is one of the biggest 
>> chunks of mpl script startup time, even with the present caching. I 
>> haven't looked very closely or done any testing, but I suspect more 
>> extensive caching could work fine. Specifically, can the entire 
>> fontManager instance be pickled, and loaded if it exists?
>>
>> Eric
>>
>>> Cheers,
>>> Mike
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Just wanted to link up this thread with a question I posed on the cairo 
mailing list.
http://lists.cairographics.org/archives/cairo/2007-August/011201.html
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
> [...]
>> One middle ground I thought of since my first message is to use 
>> fc-list to get a list of all the fonts on the system, and continue to 
>> use font_manager.py for the font matching. If "fc-list" is not 
>> available, it could fall back to the hard-coded paths it uses now. Of 
>> course, the matching in font_manager.py would still need to be improved.
> 
> Sounds reasonable.
> 
> While you are poking around in font_manager: this is one of the biggest 
> chunks of mpl script startup time, even with the present caching. I 
> haven't looked very closely or done any testing, but I suspect more 
> extensive caching could work fine. Specifically, can the entire 
> fontManager instance be pickled, and loaded if it exists?
> 
> Eric
> 
>> Cheers,
>> Mike
> 

Brandon,
I could add that method very easily, but do we really need it? Is there 
a compelling use case? You can always access the title directly as an 
attribute of the axes instance. xlabel and ylabel are other things for 
which there is a setter but not a getter. This dates from before my 
time, but I suspect the rationale is that usually all you need to do is 
set these things; and if you set them, you certainly should know what 
they are, so why get them?
Eric
Brandon Keith wrote:
> Hi,
> I just noticed matplotlib does not have a "get_title()" method. How 
> do I put it in the Axes class? Send a patch to one of the developers? 
> (It has a "set_title()" method). I noticed this when I tried a getp(p, 
> "title").
> Also, I'm preparing a graphical interface in wx's aui for matplotlib 
> that other developers might be interested in (see screenshot). It's 
> still fairly primitive but should be available soon and ready for user 
> feedback.
> 
> Thanks,
> Brandon
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi,
 I just noticed matplotlib does not have a "get_title()" method. How 
do I put it in the Axes class? Send a patch to one of the developers? 
(It has a "set_title()" method). I noticed this when I tried a getp(p, 
"title"). 
Also, I'm preparing a graphical interface in wx's aui for matplotlib 
that other developers might be interested in (see screenshot). It's 
still fairly primitive but should be available soon and ready for user 
feedback.
 
 Thanks,
 Brandon