matplotlib-devel Mailing List for matplotlib

John,
Sorry about the late replay - I've been out sick.
I don't mean to turn this around on you but it might be best if we 
could define what mathematical operations MPL requires from a 
type. Our types support all "reasonable" math ops. The examples of 
things that have caused problems in the past are things like this:
1) Converting to array and assuming the input is float (this happened 
in the last step patch that was submitted). I.e. something like this 
(from memory):
my_y = npy.asarray( y, npy.float_ )
2) Assuming numeric properties for dates. For example, if you want a 
midpoint of 2 x values, someone might write this:
xmid = 0.5 * ( x1 + x2 )
But you can't add 2 dates together so this won't work when using 
dates for x. You could do this:
xmid = x1 + 0.5 * ( x2 - x1 )
Off the top of my head, the operations that our "extended types" 
don't support are:
1) Mixing units (5*km + 4*sec). But this throws an exception so I 
don't think it's problem that MPL has to deal with.
2) Passing extended types to other routines that expect floats (like 
the math library trig functions). However, python __XXX__ math ops 
like __abs__ and __nonzero__ are supported where appropriated 
(numbers with units have __abs__ but dates don't).
3) Some math operations on times (epoch in our terminology). The 
valid operations for epochs and durations are:
epoch <,>,== epoch (i.e. __cmp__ )
duration <,>,== duration (i.e. __cmp__ )
epoch = duration + epoch
epoch = epoch - duration
duration = epoch - epoch
duration = duration + duration
duration = duration - duration
duration = float * duration
duration = duration / float
float = duration / duration
duration = abs( duration )
duration.__nonzero__
I would expect these rules to hold true for python date/time objects 
as well. The noteworthy operations that are NOT permitted are:
epoch + epoch
float * epoch
epoch / float
At 11:13 AM 11/2/2007, John Hunter wrote:
>On 11/2/07, Eric Firing <ef...@ha...> wrote:
>
> > Now I am not so sure that the use of lists in errorbar is a fossil, but
> > I certainly don't understand it. Would you give a summary of when one
> > can and cannot use arrays in axes.py, please? The errorbar and bar
> > methods seem to be the only victims of this restriction, and it looks
> > like some of the instances are accomplishing nothing--the arguments get
> > converted to arrays with the next method call anyway. I haven't tried
> > to trace things carefully, obviously.
>
>I just wrote some related stuff in the other thread, but will jump in
>here. I think I may be being overzealous in my avoidance of arrays. What
>we cannot assume is that asarray is creating an array of floats, so we
>cannot do scalar array operations, eg 2*x. But we should be able to
>assume object arrays, with indexing, and element wise opertations
>which are well defined, eg for the canonical date example.
>
>In [3]: import datetime
>
>In [4]: date0 = datetime.date(2004,1,1)
>
>In [5]: days = datetime.timedelta(days=1)
>
>In [6]: d = [date0, date0+days, date0+2*days, date0+3*days]
>
>In [7]: import numpy as n
>
>In [8]: x1 = n.array(d)
>
>In [9]: xerr = n.array([days]*len(x1))
>
>In [10]: x1.dtype
>Out[10]: dtype('object')
>
>In [11]: x2.dtype
>------------------------------------------------------------
>Traceback (most recent call last):
> File "<ipython console>", line 1, in ?
>NameError: name 'x2' is not defined
>
>
>In [12]: xerr.dtype
>Out[12]: dtype('object')
>
>
>In [13]: x1 + xerr
>Out[13]: array([2004年01月02日, 2004年01月03日, 2004年01月04日, 2004年01月05日], dtype=object)
>
>
>
>The reason we are bumping into so may problems with errorbar is not
>only because it is complex, but because it is doing more arithmetic
>than other plotting code.
>Ted, can you clarify what kinds of operations are permitted with your
>iterable unit objects if they are initialized into numpy object
>arrays?
>
>-------------------------------------------------------------------------
>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

STIX fonts seem to be break with PDF or PS font subsetting. Looking 
into it...
Cheers,
Mike
Michael Droettboom wrote:
> The STIX fonts are now passing the mathtext_examples.py unit test. This 
> font blends much better with fonts like Times.
> 
> The rcParam "mathtext.use_cm" (which is new since the last release) has 
> been replaced with "mathtext.fontset" which takes either "cm", "stix" or 
> "custom". To use the STIX fonts, set it to "stix". While "custom" 
> mostly works with the STIX fonts, "stix" will turn on a little extra 
> code that knows how to use the dynamically sized characters (such as the 
> radical sign) from the correct STIX fonts.
> 
> There are far more characters in the STIX fonts than in the Bakoma 
> fonts, and many of them are not accessible through a "named" symbol, 
> such as "\foo". At present, matplotlib only understands the common math 
> symbols in core LaTeX, and a handful of symbols defined in commonly used 
> LaTeX extension packages. Ideally, now that we have much more complete 
> fonts, we could create mappings from all the symbols in the 
> "Comprehensive LaTeX symbol list" to Unicode, but that's a considerable 
> amount of bookkeeping work, unless someone else has already done it for 
> some other project. I suspect that there's a 90/10 rule here: 90% of 
> users use 10% of the symbols, and vice versa. (It may even be more like 
> 99/1.)
> 
> As a way around this, you can insert Unicode characters directly into 
> the math string and it will correctly use that character in the STIX 
> font. For example, the following will produce a carriage return symbol:
> 
> 	ur"$\u23ce$"
> 
> This even works for the *really* rare symbols (that don't have an 
> official Unicode code point and have been placed in the "Private Use 
> Area" codepage in a separate font file)... matplotlib has a little extra 
> code to use the "Non-Unicode" fonts when necessary (when the codepoint 
> is E000 - F8FF).
> 
> Currently, there's no way to get at all of the fancy integral signs that 
> STIX provides.
> 
> Cheers,
> Mike
> 
> Michael Droettboom wrote:
>> John Hunter wrote:
>>> On 11/5/07, Darren Dale <dar...@co...> wrote:
>>>>>> If we go the route of
>>>>>> wrapping the API (which would be better anyway, since then we could look
>>>>>> for fonts in our own custom font directory), it would just be like the
>>>>>> existing dependencies on freetype and libpng. Not a big deal, really,
>>>>>> but it adds an additional maintenance burden on those Windows
>>>>>> dependencies.
>>> My inclination is to try and fix font_manager. Paul's goal was to
>>> implement the W3C specification for cross-platform font finding, which
>>> seems like a good starting point.
>> IMHO, it's just a not a very good algorithm. The key section (when an 
>> exact font-family match can not be found) is this:
>>
>> "UAs that implement intelligent matching may proceed to examine other 
>> descriptors such as x-height, glyph widths, and panose-1 to identify a 
>> different tentative font family. If there are matches for *all* the 
>> remaining descriptors, then that is the matching font face for the given 
>> element." (Emphasis mine).
>>
>> Certainly one can do better than all-or-nothing like this. Something 
>> like a weighted nearest neighbor match would result in much better near 
>> matches.
>>
>>> So far, I've heard two complaints
>>> about the current setup: font_manager will throw up its hands and
>>> return a default if an exact match fails rather than returning the
>>> closest (this doesn't seem too hard to improve upon in the existing
>>> framework)
>> Not a lot of work, but the main data structure for lookups will need to 
>> be completely different. Right now it is a tree with font-family name 
>> at the top, so if that fails it's difficult to find something close.
>>
>>> and we do not have support for OpenType (not sure how hard
>>> this would be to add).
>> That's easy -- freetype handles them correctly and the interface to the 
>> metadata ends up looking the same as a ttf file. It's only because of 
>> the different file extension that they are not being seen now. I'll 
>> have a patch shortly.
>>
>>> Are there other problems?
>> .dfont support on the Mac -- it only looks at the first font in the 
>> file. (Though, when I checked fontconfig a few months ago, it also 
>> exhibited this problem.)
>>
>> Maintaining a separate font cache means that the user must know to 
>> delete the matplotlib font cache file in order to use newly installed fonts.
>>
>> Cheers,
>> Mike
>>
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Oct 31, 2007 at 01:55:09PM -0400, Darren Dale wrote:
> > Beta versions of tarballs are on
> > http://code.enthought.com/downloads/source . I will make cleaner tarballs
> > of the release that was done last week when I get back home. These
> > tarballscan be used for eg packaging, or integrating the dependency, as
> > Fernando does in ipython.
> This is just what we are looking for. Please let me know when the new
> tarballs are available.
I forgot to let you know :->.
I made a new release on Saturday. Its a traits 2 release, not a traits 3,
but eventhough this is not the latest and greatest, this is what I use on
a day to day basis, and it is a well tested and solid release.
Gaël

On Sat, Nov 03, 2007 at 05:43:55PM +0100, Olivier Verdier wrote:
> This is much worse than I thought. The "inch" unit is used in many places in
> matplotlib. In particular in `figure` and `savefig`. Please, please consider
> allowing other units. Let me emphasise this once more: in Europe, and, I
> believe in most places around the world, one NEVER uses inches. Neither in
> engineering nor, i think, in typography. For most people "inch" is basically
> an unusual measure of how big screens are. I'm not kidding. Same for dpi,
> it's a specific measurement of a resolution but nobody thinks of it as a
> number of pixels per inches.
> I have nothing against an internal use of inches inside matplotlib but
> please consider allowing other units for all kinds of interfaces with the
> user!
> 
> The best choice in my opinion would be to have a unit preference in the
> .matplotlibrc file. This unit could be, say, `inch` or `cm` (or mm). Then
> any length would be expressed using this unit of length. That seems simple
> enough, doesn't it?
You have to be careful about the use of global flags which
change the behaviour of a library --- they make it very difficult
to write applications that work on all users machines. Consider 
an application where you have two graphs on the same page, and 
you want the axes to be aligned. The only way to do this reliably 
is to set the margin size. If you write code assuming mm and the 
users machine uses inches, the results will not be pretty.
One solution is to attach units to all your values. With a set
of base units that supports multiplication by scalars, this 
could be something like:
 figure(figsize=(100*mm,50*mm))
A sensible default such as printer points is needed if no units 
are specified.
The reason you need to carry around the units is that you may want 
the size to scale with the font. For example, you may want to 
provide for 6 digits in the tic labels, so the margin should be
ten times the width of a single digit (allowing for sign and spaces).
Currently margins and legend boxes scale with the size of the plot,
which is not ideal. 
Latex uses these units:
	mm	Millimetres
	cm	Centimetres
	in	Inches
	pt	Points (1in = 72.27pt)
	pc	Picas (1pc = 12pt)
	em	The width of the letter M in the current font
	ex	The height of the letter x in the current font
- Paul

John Hunter wrote:
> Now for my next problem: I built zlib, libpng an freetype from source
> and I get a
William Kyngesburye is building and maintaining a nice set of Universal 
Frameworks of various libs that are more or less standard on Linux:
http://www.kyngchaos.com/software/unixport/frameworks
Maybe they would be a good set to use as a standard recommendation for 
folks building/using MPL on OS-X.
I think the Freetype and UnixImageIO Frameworks would cover it for MPL.
-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...

The STIX fonts are now passing the mathtext_examples.py unit test. This 
font blends much better with fonts like Times.
The rcParam "mathtext.use_cm" (which is new since the last release) has 
been replaced with "mathtext.fontset" which takes either "cm", "stix" or 
"custom". To use the STIX fonts, set it to "stix". While "custom" 
mostly works with the STIX fonts, "stix" will turn on a little extra 
code that knows how to use the dynamically sized characters (such as the 
radical sign) from the correct STIX fonts.
There are far more characters in the STIX fonts than in the Bakoma 
fonts, and many of them are not accessible through a "named" symbol, 
such as "\foo". At present, matplotlib only understands the common math 
symbols in core LaTeX, and a handful of symbols defined in commonly used 
LaTeX extension packages. Ideally, now that we have much more complete 
fonts, we could create mappings from all the symbols in the 
"Comprehensive LaTeX symbol list" to Unicode, but that's a considerable 
amount of bookkeeping work, unless someone else has already done it for 
some other project. I suspect that there's a 90/10 rule here: 90% of 
users use 10% of the symbols, and vice versa. (It may even be more like 
99/1.)
As a way around this, you can insert Unicode characters directly into 
the math string and it will correctly use that character in the STIX 
font. For example, the following will produce a carriage return symbol:
	ur"$\u23ce$"
This even works for the *really* rare symbols (that don't have an 
official Unicode code point and have been placed in the "Private Use 
Area" codepage in a separate font file)... matplotlib has a little extra 
code to use the "Non-Unicode" fonts when necessary (when the codepoint 
is E000 - F8FF).
Currently, there's no way to get at all of the fancy integral signs that 
STIX provides.
Cheers,
Mike
Michael Droettboom wrote:
> John Hunter wrote:
>> On 11/5/07, Darren Dale <dar...@co...> wrote:
>>>>> If we go the route of
>>>>> wrapping the API (which would be better anyway, since then we could look
>>>>> for fonts in our own custom font directory), it would just be like the
>>>>> existing dependencies on freetype and libpng. Not a big deal, really,
>>>>> but it adds an additional maintenance burden on those Windows
>>>>> dependencies.
>> My inclination is to try and fix font_manager. Paul's goal was to
>> implement the W3C specification for cross-platform font finding, which
>> seems like a good starting point.
> 
> IMHO, it's just a not a very good algorithm. The key section (when an 
> exact font-family match can not be found) is this:
> 
> "UAs that implement intelligent matching may proceed to examine other 
> descriptors such as x-height, glyph widths, and panose-1 to identify a 
> different tentative font family. If there are matches for *all* the 
> remaining descriptors, then that is the matching font face for the given 
> element." (Emphasis mine).
> 
> Certainly one can do better than all-or-nothing like this. Something 
> like a weighted nearest neighbor match would result in much better near 
> matches.
> 
>> So far, I've heard two complaints
>> about the current setup: font_manager will throw up its hands and
>> return a default if an exact match fails rather than returning the
>> closest (this doesn't seem too hard to improve upon in the existing
>> framework)
> 
> Not a lot of work, but the main data structure for lookups will need to 
> be completely different. Right now it is a tree with font-family name 
> at the top, so if that fails it's difficult to find something close.
> 
>> and we do not have support for OpenType (not sure how hard
>> this would be to add).
> 
> That's easy -- freetype handles them correctly and the interface to the 
> metadata ends up looking the same as a ttf file. It's only because of 
> the different file extension that they are not being seen now. I'll 
> have a patch shortly.
> 
>> Are there other problems?
> 
> .dfont support on the Mac -- it only looks at the first font in the 
> file. (Though, when I checked fontconfig a few months ago, it also 
> exhibited this problem.)
> 
> Maintaining a separate font cache means that the user must know to 
> delete the matplotlib font cache file in order to use newly installed fonts.
> 
> Cheers,
> Mike
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John Hunter wrote:
> On 11/5/07, Darren Dale <dar...@co...> wrote:
>>>> If we go the route of
>>>> wrapping the API (which would be better anyway, since then we could look
>>>> for fonts in our own custom font directory), it would just be like the
>>>> existing dependencies on freetype and libpng. Not a big deal, really,
>>>> but it adds an additional maintenance burden on those Windows
>>>> dependencies.
> 
> My inclination is to try and fix font_manager. Paul's goal was to
> implement the W3C specification for cross-platform font finding, which
> seems like a good starting point.
IMHO, it's just a not a very good algorithm. The key section (when an 
exact font-family match can not be found) is this:
"UAs that implement intelligent matching may proceed to examine other 
descriptors such as x-height, glyph widths, and panose-1 to identify a 
different tentative font family. If there are matches for *all* the 
remaining descriptors, then that is the matching font face for the given 
element." (Emphasis mine).
Certainly one can do better than all-or-nothing like this. Something 
like a weighted nearest neighbor match would result in much better near 
matches.
> So far, I've heard two complaints
> about the current setup: font_manager will throw up its hands and
> return a default if an exact match fails rather than returning the
> closest (this doesn't seem too hard to improve upon in the existing
> framework)
Not a lot of work, but the main data structure for lookups will need to 
be completely different. Right now it is a tree with font-family name 
at the top, so if that fails it's difficult to find something close.
> and we do not have support for OpenType (not sure how hard
> this would be to add).
That's easy -- freetype handles them correctly and the interface to the 
metadata ends up looking the same as a ttf file. It's only because of 
the different file extension that they are not being seen now. I'll 
have a patch shortly.
> Are there other problems?
.dfont support on the Mac -- it only looks at the first font in the 
file. (Though, when I checked fontconfig a few months ago, it also 
exhibited this problem.)
Maintaining a separate font cache means that the user must know to 
delete the matplotlib font cache file in order to use newly installed fonts.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On 11/4/07, Eric Firing <ef...@ha...> wrote:
> John, Fernando,
>
> Is it OK to remove the hack now? In pyplot.py:
>
> # a hack to keep old versions of ipython working with mpl after bug
> # fix #1209354
This was added in 2005 when mpl was at 0.83 and ipython was at 0.6.15,
so yes, it is OK to remove it now. If someone wants to run the latest
mpl, surely they can upgrade ipython.
JDH

On 11/5/07, Darren Dale <dar...@co...> wrote:
> > > If we go the route of
> > > wrapping the API (which would be better anyway, since then we could look
> > > for fonts in our own custom font directory), it would just be like the
> > > existing dependencies on freetype and libpng. Not a big deal, really,
> > > but it adds an additional maintenance burden on those Windows
> > > dependencies.
My inclination is to try and fix font_manager. Paul's goal was to
implement the W3C specification for cross-platform font finding, which
seems like a good starting point. So far, I've heard two complaints
about the current setup: font_manager will throw up its hands and
return a default if an exact match fails rather than returning the
closest (this doesn't seem too hard to improve upon in the existing
framework) and we do not have support for OpenType (not sure how hard
this would be to add). Are there other problems?
While I am sympathetic to the desire to depend on standard,
maintained-by-someone-else, packages, I am also sympathetic to the
problems of users on a variety of platforms who are currently finding
mpl hard to build and install ( I had my own troubles on a new box
this weekend). If everyone were on ubuntu, life would be great, but
in the current environment adding a dependency (fontconfig) which
also has a dependency (xml parser) is a lot to take on.
I am definitely -1 on calling out to the command line. So if the
consensus is that we really need fontconfig, I would be inclined to
wrap the API and bring it in as an optional build dependency. Nadia
looked at this at one point: having a repository of dependencies which
the mpl could grab, unpack and build if needed. A general solution
for zlib, png, freetype and possibly fontconfig and friends would be a
welcome addition for OS X and win32 users.
JDH

On Monday 05 November 2007 8:49:01 am Darren Dale wrote:
> On Monday 05 November 2007 8:07:04 am you wrote:
> > Darren Dale wrote:
> > > On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote:
> > >> This is maybe another push in the direction of using fontconfig (which
> > >> claims to support otf fonts already). I'd really prefer to go in that
> > >> direction rather than continue to tack on partial reimplementations of
> > >> it in font_manager.py -- but it does complicate dependencies on
> > >> non-X11 platforms).
> > >
> > > What are the dependency problems? I thought freetype was the only
> > > requirement. Incidentally, GIMP uses fontconfig on windows, and they
> > > comment at http://www.gimp.org/~tml/gimp/win32/downloads.html:
> > > "Contrary to what many seem to think, fontconfig is in no way dependent
> > > on X11, so it does make some sense to use it on Windows."
> >
> > Fontconfig depends on freetype and either expat or libxml2 (expat being
> > the easier/lighter dependency).
>
> Oh, your right.
>
> > But the real dependency problem is that on Windows it generally isn't
> > already there. So it would have to be added to the external windows
> > dependency zip, and we would probably have to go through a few
> > contortions to call it as a commandline tool.
>
> I wonder if that comes with additional overhead.
>
> > If we go the route of
> > wrapping the API (which would be better anyway, since then we could look
> > for fonts in our own custom font directory), it would just be like the
> > existing dependencies on freetype and libpng. Not a big deal, really,
> > but it adds an additional maintenance burden on those Windows
> > dependencies.
> >
> > On the Mac, fontconfig appears to be installed as part of Apple's X11
> > distribution, but not without it, even though it is useful outside of
> > X11.
> >
> > So, in case you can't tell, I've long been torn by this -- fontconfig
> > solves the font lookup problem in a much more robust way than matplotlib
> > will probably ever have the resources to do. On the other hand, it adds
> > complexity to the matplotlib build req's. Perhaps if there were buy-in
> > from some regular Windows and Mac devels to help maintain this going
> > forward I wouldn't be so hesitant.
>
> Thanks for explaining. What a headache. I wonder what other cross-platform
> applications and libraries use to deal with fonts, like Qt and OpenOffice.
> Are there native alternatives to fontconfig that are universally installed
> on mac and windows? Or do all these projects have to roll their own
> solution like we do?
(That was a rhetorical question. I know we have gone around these circles a 
couple times before now.)

On Monday 05 November 2007 8:07:04 am you wrote:
> Darren Dale wrote:
> > On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote:
> >> This is maybe another push in the direction of using fontconfig (which
> >> claims to support otf fonts already). I'd really prefer to go in that
> >> direction rather than continue to tack on partial reimplementations of
> >> it in font_manager.py -- but it does complicate dependencies on non-X11
> >> platforms).
> >
> > What are the dependency problems? I thought freetype was the only
> > requirement. Incidentally, GIMP uses fontconfig on windows, and they
> > comment at http://www.gimp.org/~tml/gimp/win32/downloads.html: "Contrary
> > to what many seem to think, fontconfig is in no way dependent on X11, so
> > it does make some sense to use it on Windows."
>
> Fontconfig depends on freetype and either expat or libxml2 (expat being
> the easier/lighter dependency).
Oh, your right.
> But the real dependency problem is that on Windows it generally isn't
> already there. So it would have to be added to the external windows
> dependency zip, and we would probably have to go through a few
> contortions to call it as a commandline tool.
I wonder if that comes with additional overhead.
> If we go the route of 
> wrapping the API (which would be better anyway, since then we could look
> for fonts in our own custom font directory), it would just be like the
> existing dependencies on freetype and libpng. Not a big deal, really,
> but it adds an additional maintenance burden on those Windows dependencies.
>
> On the Mac, fontconfig appears to be installed as part of Apple's X11
> distribution, but not without it, even though it is useful outside of X11.
>
> So, in case you can't tell, I've long been torn by this -- fontconfig
> solves the font lookup problem in a much more robust way than matplotlib
> will probably ever have the resources to do. On the other hand, it adds
> complexity to the matplotlib build req's. Perhaps if there were buy-in
> from some regular Windows and Mac devels to help maintain this going
> forward I wouldn't be so hesitant.
Thanks for explaining. What a headache. I wonder what other cross-platform 
applications and libraries use to deal with fonts, like Qt and OpenOffice. 
Are there native alternatives to fontconfig that are universally installed on 
mac and windows? Or do all these projects have to roll their own solution 
like we do?

Darren Dale wrote:
> On Sunday 04 November 2007 8:50:48 am Michael Droettboom wrote:
>> This is maybe another push in the direction of using fontconfig (which
>> claims to support otf fonts already). I'd really prefer to go in that
>> direction rather than continue to tack on partial reimplementations of it
>> in font_manager.py -- but it does complicate dependencies on non-X11
>> platforms).
> 
> What are the dependency problems? I thought freetype was the only requirement. 
> Incidentally, GIMP uses fontconfig on windows, and they comment at 
> http://www.gimp.org/~tml/gimp/win32/downloads.html: "Contrary to what many 
> seem to think, fontconfig is in no way dependent on X11, so it does make some 
> sense to use it on Windows."
Fontconfig depends on freetype and either expat or libxml2 (expat being 
the easier/lighter dependency).
But the real dependency problem is that on Windows it generally isn't 
already there. So it would have to be added to the external windows 
dependency zip, and we would probably have to go through a few 
contortions to call it as a commandline tool. If we go the route of 
wrapping the API (which would be better anyway, since then we could look 
for fonts in our own custom font directory), it would just be like the 
existing dependencies on freetype and libpng. Not a big deal, really, 
but it adds an additional maintenance burden on those Windows dependencies.
On the Mac, fontconfig appears to be installed as part of Apple's X11 
distribution, but not without it, even though it is useful outside of X11.
So, in case you can't tell, I've long been torn by this -- fontconfig 
solves the font lookup problem in a much more robust way than matplotlib 
will probably ever have the resources to do. On the other hand, it adds 
complexity to the matplotlib build req's. Perhaps if there were buy-in 
from some regular Windows and Mac devels to help maintain this going 
forward I wouldn't be so hesitant.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

John, Fernando,
Is it OK to remove the hack now? In pyplot.py:
# a hack to keep old versions of ipython working with mpl after bug
# fix #1209354
if 'IPython.Shell' in sys.modules:
 from matplotlib.backends import new_figure_manager, 
draw_if_interactive, show
else:
 from matplotlib.backends import pylab_setup
 new_figure_manager, draw_if_interactive, show = pylab_setup()
It is not a big deal, but in the interests of simplification and cleanup 
I would like to remove this (and related lines in backends/__init__.py) 
if it is ancient and no longer needed.
Eric