matplotlib-devel Mailing List for matplotlib (Page 10)

John Hunter wrote:
> On Nov 6, 2007 1:36 PM, Michael Droettboom <md...@st...> wrote:
>> There is, of course, some time and memory overhead to loading larger
>> fonts, but it may not be significant.
>>
>> The other issue with subsetting the fonts before distributing them is
>> just a matter of person-time: someone has to write the scripts to do it,
>> and then re-run them when the STIX fonts are updated.
> 
> Sounds good to me -- if there were a big savings in file size I
> thought it might be worth looking into, but he who writes the code
> gets the most votes :-)
Not sure -- Maybe we were talking about different things... I was 
talking about actually removing individual glyphs from the files -- that 
may result in much larger savings percentage-wise, but would be 
labor-intensive. Removing whole font files is quite easy (and I 
actually did remove the files that mathtext can't currently access).
> I think we should make stix the default for mathtext.fontset once you
> get these changes incorporated, presuming PDF and PS work as expected
> -- is there any reason not to?
No reason, other than the usual "hasn't been tested as much", and how 
that may affect the upcoming release. I anticipate more mis-mapped 
glyphs (I found some already, but I'm sure not all of them). But it 
won't get tested much unless people are nudged into using it ;) I'd 
encourage people on this list to kick it around a bit before we widen 
the audience. But don't let that hold back the release -- it's always 
hard to know when to press that big red button... ;)
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Nov 6, 2007 1:36 PM, Michael Droettboom <md...@st...> wrote:
> There is, of course, some time and memory overhead to loading larger
> fonts, but it may not be significant.
>
> The other issue with subsetting the fonts before distributing them is
> just a matter of person-time: someone has to write the scripts to do it,
> and then re-run them when the STIX fonts are updated.
Sounds good to me -- if there were a big savings in file size I
thought it might be worth looking into, but he who writes the code
gets the most votes :-)
I think we should make stix the default for mathtext.fontset once you
get these changes incorporated, presuming PDF and PS work as expected
-- is there any reason not to?
JDH

John Hunter wrote:
> On Nov 6, 2007 1:05 PM, Michael Droettboom <md...@st...> wrote:
> 
>> This fontforge script seems to do the conversion quite well:
>>
>> #!/usr/bin/fontforge
>> Open(1ドル);
>> Generate(1ドル:r+".ttf");
>> Quit(0);
>>
>> If there are no objections, I'll go ahead and do that and commit the
>> results.
> 
> This certainly seems to be the path of least resistance. Would there
> be much savings in terms of file size if we just extracted the fonts
> we need, eg the parts we need for latex expressions. If a significant
> portion of the fonts are relatively inaccessible unicode, maybe we
> should just distribute the subset we need.
Now that subsetting works, I'd be more inclined to just include 
everything and let the backends sort it out. The total filesize of all 
the STIX fonts converted to .ttf is 1,334,524 bytes. Removing the font 
files that matplotlib can't currently access at all, the total is 
1,167,920 bytes.
I don't consider that to be a large amount of space anymore. 
(Sourceforge provides the hosting and bandwidth anyway, right? ;)
There is, of course, some time and memory overhead to loading larger 
fonts, but it may not be significant.
The other issue with subsetting the fonts before distributing them is 
just a matter of person-time: someone has to write the scripts to do it, 
and then re-run them when the STIX fonts are updated.
In the meantime, I'll commit the .ttf versions of the STIX fonts, and 
remove the .otf versions, which doesn't preclude subsetting the fonts 
further down the road.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Darren Dale wrote:
> On Sunday 04 November 2007 9:04:15 am Michael Droettboom wrote:
>> I should also add -- it would be really nice to have STIX fonts working in
>> the upcoming stable release if possible. Hopefully tomorrow morning I can
>> assess how much work that will be and maybe delay tagging the release
>> slightly so this can be worked through. It would be nice to remove the
>> Computer Modern fonts (in mathtext only), but they still serve a niche in
>> that they match the LaTeX fonts for users who can't/won't use usetex. So
>> we're probably stuck with them for the long term even if STIX becomes a
>> nicer/cleaner option.
> 
> I haven't found sans-serif or monospaced fonts in their distribution. Maybe I 
> don't know where to look. I sent an email to the STIX website asking about 
> them, but havent heard back from them. I tried opening the fonts in 
> fontforge, and there are a lot of missing glyphs.
Unicode includes a "Mathematical Alphanumeric Symbols" range 
1D400-1D7FF. The STIXGeneral font includes some (not all) sans-serif 
and monospaced Greek and Latin glyphs in that range. Mathtext won't 
actually use them yet, but doing so should be reasonably straightforward.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Fernando Perez wrote:
> On 11/5/07, John Hunter <jd...@gm...> wrote:
>> 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.
> 
> Agreed from this side.
> 
> Cheers,
> 
> f
Fernando,
Thanks. I did it.
Eric

On Nov 6, 2007 1:05 PM, Michael Droettboom <md...@st...> wrote:
> This fontforge script seems to do the conversion quite well:
>
> #!/usr/bin/fontforge
> Open(1ドル);
> Generate(1ドル:r+".ttf");
> Quit(0);
>
> If there are no objections, I'll go ahead and do that and commit the
> results.
This certainly seems to be the path of least resistance. Would there
be much savings in terms of file size if we just extracted the fonts
we need, eg the parts we need for latex expressions. If a significant
portion of the fonts are relatively inaccessible unicode, maybe we
should just distribute the subset we need.
JDH

Mike,
Thanks for the quick response.
I was wrong as usual: the masked array overhead in your original version 
of the path initializer was actually small. I misinterpreted the 
kcachegrind display. Rats! I was hoping for a big gain. It looks like 
anything that makes a huge number of paths is going to be slow, no 
matter what we do to try to optimize the path initializer.
A partial solution for pcolor is pcolormesh, using the quadmesh 
extension code, although that still has a bug. (Paul Kienzle was going 
to look into it.) Is the quadmesh extension compatible with your 
transforms branch?
My impression is that the transforms branch is going to be a big step 
forward, with performance improvements in some areas, at worst minor 
penalties in others--except for some problems like pcolor that need to 
be solved.
In order to replace matlab in my application, a very fast interactive 
pcolor-type capability is absolutely essential. I think this simply has 
to be done via extension code, like quadmesh and the image codes. 
(Pcolor in the trunk isn't fast enough, either.) Unfortunately, I have 
found those codes hard to understand. Only the regular-grid image code 
is fully integrated into the trunk, and even it has a long-standing bug 
revealed by extreme zooming. The irregular-grid image routine might be 
a big help, but it has never been integrated. I don't remember which 
bugs it shares with quadmesh and image, if any.
Eric
Michael Droettboom wrote:
> Eric Firing wrote:
>> Mike,
>>
>> I made a quick test and took a quick look, and I certainly see a ripe 
>> mango within reach. I don't know what your constraints and strategy 
>> are, but I thought I would give you the off-the-cuff idea before I 
>> forget what I did.
>>
>> The test was pcolortest.py, and the kcachegrind input is the .log file.
>>
>> The problem is the path initializer: it is converting everything to a 
>> masked array, which in the vast majority of cases is not needed, and is 
>> very costly.
> 
> Thanks for finding this. I agree completely. I think that was 
> basically a typo that ended up "working", just suboptimally. The input 
> to the path constructor may be either a numpy array, an ma array or a 
> regular Python sequence. If it's the first two, it should be left alone 
> (if there is an array mask, it is dealt with later on in the 
> constructor), but if the latter, it should be converted to a numpy array.
> 
> What I meant to type was:
> 
> if not ma.isMaskedArray(vertices):
> vertices = npy.asarray(vertices, npy.float_)
> 
> The argument against just "npy.asarray(vertices, npy.float_)" is that 
> the mask needs to be preserved.
> 
> If I understand correctly, that will be essentially a no-op when the 
> input is a numpy array, albeit with the overhead of some checks.
> 
>> We need to think carefully about the levels of API, and what should be 
>> done at which levels. One possibility is that at the level of the path 
>> initializer, only ordinary ndarrays should be acceptable--any mask 
>> manipulations and compressions should already have been done. This 
>> would require a helper function to generate the codes for that case. 
>> Another is that the path initializer could get a flag telling it whether 
>> to check for masked arrays. And another is that a check for existance 
>> of a mask should be done at the start, and the mask processing done only 
>> if there is a mask.
> 
> This option was the intent.
> 
>> Yet another is that if a mask is needed, it be 
>> passed in as an optional 1-D array kwarg. An advantage of this is that 
>> the code that calls the path initializer may be in a better position to 
>> know what is needed to generate the 1-D mask (that is, a mask for each 
>> (x,y) point rather than for x and y separately)--that mask may already 
>> be sitting around.
> 
> Many of these options I fear would significantly complicate the code. 
> One of the driving motivations for the refactoring is to allow 
> transformations to be combined more generally. Think of the case where 
> you have a polar plot with a logarithmic scale on the r-axis (this 
> wasn't ever possible in the trunk). The log scale means that there is 
> potential for negative masked values, but the polar part of the 
> transformation shouldn't have to know or care whether masked values are 
> being passed through. Requiring it to do so would need the same checks 
> currently performed in the Path constructor, but they would be copied 
> all over the code in every kind of new transformation.
> 
> FWIW, there already is a deliberate "quarantining" of masked arrays -- 
> it happens where the logical elements of the plot hit the drawing 
> commands of the plot (the Path object). It could have been implemented 
> such that the backends must understand masked arrays and draw 
> accordingly, but it proved to be faster (based on the simple_plot_fps.py 
> benchmark) to convert to a non-masked array with MOVETO codes upfront 
> and reuse that. (Not surprising, given the overhead of masked arrays). 
> This means that masked arrays are not used at all during panning and 
> zooming operations where speed is perhaps the most crucial.
> 
>> Masked arrays are pretty clunky and slow. The maskedarray 
>> implementation by Pierre GM is nicer, more complete, and faster for many 
>> operations than numpy.ma, but it still adds a lot of overhead, 
>> especially for small arrays. (It needs to have its core in C; so far I 
>> have failed dismally in trying to understand how to do that without 
>> repeating the bulk of the ndarray code.)
>>
>> A related point: can you (or is it OK if I do it) change all the "import 
>> numpy.ma as ma" or whatever to "from matplotlib.numerix import npyma as 
>> ma"? The advantage is that it makes it easy to test the new version 
>> with either maskedarray or ma. This should be temporary; I am still 
>> hoping and expecting that maskedarray will replace ma in the core numpy 
>> distribution.
> 
> That sounds like a very good idea. I'll go ahead and do this (on the 
> branch only).
> 
> Cheers,
> Mike
> 

On 11/5/07, John Hunter <jd...@gm...> wrote:
> 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.
Agreed from this side.
Cheers,
f

The STIX fonts are provided as OpenType wrappers around Adobe Compact 
Font Format (CFF or Type 2) fonts (sometimes called OpenType CFF or 
'OTTO' font, because of the header tag on these files). With the Agg 
backend, this isn't a problem, since freetype supports these fonts 
transparently. However, the Ps and Pdf backends are more-or-less 
hardwired for TrueType fonts and will need to have significant tricky 
bits of code glued on to support these fonts.
<DETAILS>
In the PDF backend, the fonts work, with the exception of subsetting. I 
have patched the PDF backend so that it will fall back to the 
non-subsetting font output when it encounters an OpenType CFF font. 
This is not ideal, since the STIX fonts are so large.
The Ps backend does not support these fonts at all -- I have patched it 
to raise an exception when you try to use an OpenType CFF font. New 
code would need to be written to extract the CFF section from the 
OpenType wrapper and embed it in the PostScript drawing. I made a first 
attempt at this, but couldn't get it to work. The PostScript spec 
provides an example of wrapping the CFF in a PostScript wrapper, but not 
actually embedding the CFF in a Postscript drawing... Perhaps others on 
this list have some thoughts.
Agg, SVG and Cairo backends are working.
Long term, I think the font subsetting code should be rewritten so that 
it works with freetype (which understands all kinds of input font 
formats) on the input end, and then we should dump ttconv. (I say that 
regretfully, having been the one to suggest ttconv in the first place). 
 The SVG backend already works like this. The reason the Ps and Pdf 
backends didn't go that route was to avoid dealing with the intricacies 
of writing those more complex font formats.
</DETAILS>
All that said (and sorry for the gory details), if we just convert the 
OTF STIX fonts to TTF, all these problems go away. matplotlib supports 
.ttf fonts quite well at this point. As Darren pointed out, the STIX 
license allows this conversion:
"""
 3. You may (a) convert the Fonts from one format to another (e.g.,
from TrueType to PostScript), in which case the normal and reasonable
distortion that occurs during such conversion shall be permitted and (b)
embed or include a subset of the Fonts in a document for the purposes of
allowing users to read text in the document that utilizes the Fonts. In
each case, you may use the STIX Fonts-TM mark to designate the resulting
Fonts or subset of the Fonts.
"""
This fontforge script seems to do the conversion quite well:
	#!/usr/bin/fontforge
	Open(1ドル);
	Generate(1ドル:r+".ttf");
	Quit(0);
If there are no objections, I'll go ahead and do that and commit the 
results.
Cheers,
Mike
Michael Droettboom wrote:
> 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

Eric Firing wrote:
> Mike,
> 
> I made a quick test and took a quick look, and I certainly see a ripe 
> mango within reach. I don't know what your constraints and strategy 
> are, but I thought I would give you the off-the-cuff idea before I 
> forget what I did.
> 
> The test was pcolortest.py, and the kcachegrind input is the .log file.
> 
> The problem is the path initializer: it is converting everything to a 
> masked array, which in the vast majority of cases is not needed, and is 
> very costly.
Thanks for finding this. I agree completely. I think that was 
basically a typo that ended up "working", just suboptimally. The input 
to the path constructor may be either a numpy array, an ma array or a 
regular Python sequence. If it's the first two, it should be left alone 
(if there is an array mask, it is dealt with later on in the 
constructor), but if the latter, it should be converted to a numpy array.
What I meant to type was:
 if not ma.isMaskedArray(vertices):
 vertices = npy.asarray(vertices, npy.float_)
The argument against just "npy.asarray(vertices, npy.float_)" is that 
the mask needs to be preserved.
If I understand correctly, that will be essentially a no-op when the 
input is a numpy array, albeit with the overhead of some checks.
> We need to think carefully about the levels of API, and what should be 
> done at which levels. One possibility is that at the level of the path 
> initializer, only ordinary ndarrays should be acceptable--any mask 
> manipulations and compressions should already have been done. This 
> would require a helper function to generate the codes for that case. 
> Another is that the path initializer could get a flag telling it whether 
> to check for masked arrays. And another is that a check for existance 
> of a mask should be done at the start, and the mask processing done only 
> if there is a mask.
This option was the intent.
> Yet another is that if a mask is needed, it be 
> passed in as an optional 1-D array kwarg. An advantage of this is that 
> the code that calls the path initializer may be in a better position to 
> know what is needed to generate the 1-D mask (that is, a mask for each 
> (x,y) point rather than for x and y separately)--that mask may already 
> be sitting around.
Many of these options I fear would significantly complicate the code. 
One of the driving motivations for the refactoring is to allow 
transformations to be combined more generally. Think of the case where 
you have a polar plot with a logarithmic scale on the r-axis (this 
wasn't ever possible in the trunk). The log scale means that there is 
potential for negative masked values, but the polar part of the 
transformation shouldn't have to know or care whether masked values are 
being passed through. Requiring it to do so would need the same checks 
currently performed in the Path constructor, but they would be copied 
all over the code in every kind of new transformation.
FWIW, there already is a deliberate "quarantining" of masked arrays -- 
it happens where the logical elements of the plot hit the drawing 
commands of the plot (the Path object). It could have been implemented 
such that the backends must understand masked arrays and draw 
accordingly, but it proved to be faster (based on the simple_plot_fps.py 
benchmark) to convert to a non-masked array with MOVETO codes upfront 
and reuse that. (Not surprising, given the overhead of masked arrays). 
 This means that masked arrays are not used at all during panning and 
zooming operations where speed is perhaps the most crucial.
> Masked arrays are pretty clunky and slow. The maskedarray 
> implementation by Pierre GM is nicer, more complete, and faster for many 
> operations than numpy.ma, but it still adds a lot of overhead, 
> especially for small arrays. (It needs to have its core in C; so far I 
> have failed dismally in trying to understand how to do that without 
> repeating the bulk of the ndarray code.)
> 
> A related point: can you (or is it OK if I do it) change all the "import 
> numpy.ma as ma" or whatever to "from matplotlib.numerix import npyma as 
> ma"? The advantage is that it makes it easy to test the new version 
> with either maskedarray or ma. This should be temporary; I am still 
> hoping and expecting that maskedarray will replace ma in the core numpy 
> distribution.
That sounds like a very good idea. I'll go ahead and do this (on the 
branch only).
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Mike,
I made a quick test and took a quick look, and I certainly see a ripe 
mango within reach. I don't know what your constraints and strategy 
are, but I thought I would give you the off-the-cuff idea before I 
forget what I did.
The test was pcolortest.py, and the kcachegrind input is the .log file.
The problem is the path initializer: it is converting everything to a 
masked array, which in the vast majority of cases is not needed, and is 
very costly.
We need to think carefully about the levels of API, and what should be 
done at which levels. One possibility is that at the level of the path 
initializer, only ordinary ndarrays should be acceptable--any mask 
manipulations and compressions should already have been done. This 
would require a helper function to generate the codes for that case. 
Another is that the path initializer could get a flag telling it whether 
to check for masked arrays. And another is that a check for existance 
of a mask should be done at the start, and the mask processing done only 
if there is a mask. Yet another is that if a mask is needed, it be 
passed in as an optional 1-D array kwarg. An advantage of this is that 
the code that calls the path initializer may be in a better position to 
know what is needed to generate the 1-D mask (that is, a mask for each 
(x,y) point rather than for x and y separately)--that mask may already 
be sitting around.
Masked arrays are pretty clunky and slow. The maskedarray 
implementation by Pierre GM is nicer, more complete, and faster for many 
operations than numpy.ma, but it still adds a lot of overhead, 
especially for small arrays. (It needs to have its core in C; so far I 
have failed dismally in trying to understand how to do that without 
repeating the bulk of the ndarray code.)
A related point: can you (or is it OK if I do it) change all the "import 
numpy.ma as ma" or whatever to "from matplotlib.numerix import npyma as 
ma"? The advantage is that it makes it easy to test the new version 
with either maskedarray or ma. This should be temporary; I am still 
hoping and expecting that maskedarray will replace ma in the core numpy 
distribution.
Eric

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

As a general note, I built MatPlotlib-SVN on Leopard against the 
Apple Python, using the numpy, libz, freetype, and png that are 
included with Leopard.
It seems to work fine, superficially; I have not run extensive 
regressions with it yet.
I can send along a MacPorts portfile (including patches) tomorrow; 
(my Leopard problem is that SSH won't respond so I can't get to my 
office machine from home).
I have some opinions about your other questions, the answers are to 
set specific environment variables.
However, my answers MIGHT BE WRONG because I can't test these at the 
moment (see ssh problem, above)
So take these responses with some skepticism. But perhaps they can 
point you in a helpful direction:
On Nov 4, 2007, at 6:29 AM, John Hunter wrote:
> Now for my next problem: I built zlib, libpng an freetype from source
> and I get a
>
> ld: warning in /Developer/SDKs/MacOSX10.4u.sdk/usr/local/lib/ 
> libpng.dylib,
> file is not of required architecture
Hmm, what about setting a MACOSX_DEPLOYMENT_TARGET=10.5
>
> error when building mpl. Is there an easy way in the
> configure/make/make install cycle to tell the compiler to build
> universal binaries?
I believe that "generic" autoconf would pick up CFLAGS:
CFLAGS="-arch ppc -arch i386"
> Alternatively, can I instruct distutils to simply not provide the
> -arch ppc build?
Distutils uses ARCHFLAGS -- if you are using the Python from Apple 
Leopard:
ARCHFLAGS="-arch i386"