matplotlib-devel Mailing List for matplotlib

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