matplotlib-devel Mailing List for matplotlib (Page 6)

Eric Firing wrote:
> Similarly, after dealing with mlab, I would like to simplify pylab. 
> Right now, we have a horrible tangle of namespaces in pylab. Cleaning 
> this up will potentially break user code; if a numpy function formerly 
> could be referenced with three different names and we knock that down to 
> one, code using the other two will not work. My guess is that in 
> practice the amount of breakage will be *very* small and easy for users 
> to deal with.
Speaking off the top of my head, without looking at the specifics -- 
would it be useful to generate deprecation warnings for these functions 
before we ultimately remove them? The deprecated functions could just 
be decorated versions of the "correct" functions that raise a warning 
and then delegate to the correct version.
May be overkill if these functions really are in low usage, as you suspect.
Cheers,
Mike

I have been gradually numpifying mlab.py; I hope this is not a 
duplication of effort with someone else. I have not finished yet (and 
have made no commits), and it may still take a while--there are a lot of 
things to change, and I am trying to do some cleaning up and 
rationalization, not just mechanical numpification. I will probably 
commit a mlab1.py version so as to facilitate some extra testing before 
making the switch.
I am trying to simplify and shrink the mlab namespace, with the idea 
that if a function exists in modern numpy it should simply be imported 
from there.
Similarly, after dealing with mlab, I would like to simplify pylab. 
Right now, we have a horrible tangle of namespaces in pylab. Cleaning 
this up will potentially break user code; if a numpy function formerly 
could be referenced with three different names and we knock that down to 
one, code using the other two will not work. My guess is that in 
practice the amount of breakage will be *very* small and easy for users 
to deal with.
Eric

Mike,
Thanks for fixing pycxx to remove all those warnings!
I am curious: have you looked at the most recent upstream pycxx? My 
impression is that there were supposedly some changes to support python 
2.5, and a couple months ago I made a feeble and unsuccessful attempt to 
use the updated version in place of the one included in mpl.
In any case, perhaps your improvements can be incorporated upstream.
Longer term, I will be pleased if our dependence on pycxx can be removed.
Eric

I'll be away until the 18th, so hold down the fort!
JDH

Hello,
I have a short "wishlist" of some features that I think should be 
implemented in matplotlib:
- More scatter symbols:
 I had submitted a patch some time ago that adds more scatter symbols 
(http://sourceforge.net/tracker/index.php?func=detail&aid=1667100&group_id=80706&atid=560722). 
there is, however, one scatter symbol which I think should be added: 
_points_. Especially in astronomy you sometimes want to show lots and 
lots of data-points in a scatter plot and point-like symbols are the 
only reasonable way to do this (-> supermongo can do this very nicely). 
I know, I can set the size of a marker to a very small number, but I 
have the feeling that a native point scatter symbol would be better/faster.
- Different "caps" for error-bars:
 It should be possible to draw different caps for the errorbars. 
People e.g. indicate upper or lower limits for errors by plotting an 
arrow-like caps; other symbols might also be useful !?
- Advanced legends:
 When trying to create a legend for a scatter plot, matplotlib only 
shows rectangular patches with the color of the scatter symbol. This is 
not very satisfying, especially for black&white printouts in 
publications when multiple symbols are chosen. e.g. triangles vs. 
squares. The legend should clarify what do triangles mean, what do 
squares mean. There is a scatter command, so the legend should properly 
handle a scatter plot - otherwise one could completely ignore scatter 
and only use the plot command.
Please don't misunderstand me - I really like matplotlib :-)
These are just some ideas which came into my mind these days. (Please 
tell me if I have missed some features that are already implemented in 
matplotlib ;-) )
Is there any chance that some of the above wished might be implemented?
Manuel
-- 
---------------------------------------
 Manuel Metz ............ Stw@AIfA
 Argelander Institut fuer Astronomie
 Auf dem Huegel 71 (room 3.06)
 D - 53121 Bonn
 E-Mail: mm...@as...
 Web: www.astro.uni-bonn.de/~mmetz
 Phone: (+49) 228 / 73-3660
 Fax: (+49) 228 / 73-3672
---------------------------------------

John Hunter wrote:
> On 8/6/07, Michael Droettboom <md...@st...> wrote:
> 
>> 1) mathtext_example_default_hinting.png - Uses freetype's default
>> hinting which uses hinting information in the file along with
>> auto-hinting to get around some patents. This is what matplotlib was
>> using when I got here.
> 
> I am still a bit confused here -- since the bakoma cm fonts presumably
> include hinting, why is it so bad? Is it just that the hinting
> information in them is not good, and some of the autohinting
> approaches below are simply better? I initially thought the problem
> was that they didn't include hinting...
I haven't been able to find a way to determine if a font has embedded 
hinting information. However, I should have mentioned that Freetype by 
default will use the embedded hinting or fallback on auto-hinting. 
There is also an option, FT_LOAD_FORCE_AUTOHINT that will ignore the 
embedded hinting. It produced identical results to FT_LOAD_DEFAULT, so 
I presume the fonts have no embedded hinting, which sort of makes sense, 
given their pedigree. However, I'm flying blind on that, so if anyone 
can suggest a way to prove that, let me know.
My original conjecture (which I admit wasn't worded very carefully) was 
that if they included manually-tweaked hinting, they might look better 
than if they were auto-hinted. Since no one is about to add manual 
hinting to the font, we'll probably never know ;)
>> 2) mathtext_example_light.png - Uses freetype's "light" hinting.
> 
> To my eyes, the biggest problems are in plain roman text, eg \sin, and
> I think 1 and 2 both fail this case pretty badly (eg example 10 in
> your output). TO my eyes, no hinting looks better than light hinting
> for these examples (and 4 is best)
> 
>> 3) mathtext_example_nohint.png - All hinting off.
>>
>> 4) mathtext_example_vert_hinting.png - This follows the suggestion in
>> Maxim's article to hint only in the vertical direction. Since freetype
>> doesn't support that natively, it uses a hack where you set the x-dpi to
>> be much higher than the y-dpi, thereby hinting the x-direction to a much
> 
> I guess beauty is in the eye of the holder, but at screen resolution I
> am not seeing too much difference in the italic 'i' and 'y'.
It's subjective, but the hook in the upper-left corner of 'y' looks 
really anemic to me in 1) and 2). Likewise the hooks on the 'i' get too 
thin.
> But for
> roman text, eg the "c" in "braces" in example 7 and "sin" in example
> 10, I think 3 and 4 are the best two, with 4 getting the nod.
I think you and I are seeing the same thing: a general thinness or 
unevenness.
> If it is simply a case where the bakoma hinting is bad, and another
> set of fonts with better hinting will solve the problem using default
> hinting, we could opt to turn hinting off until we get a better set of
> fonts.
That's the easy solution. Unfortunately, Vera Sans looks pretty wobbly 
without vertical hinting.
> As for uglifying ft2font, presumably we could encapsulate the
> ugliness into a helper class so we could say things like
> o.get_metrics_unstretched() and o.get_metrics_stretched() and the rest
> of the code would remain non-uglified..... But I'm just arm-chair
> quarterbacking here....
Unfortunately, it's a lot more pervasive than just that one function. 
But if all calls to get freetype metrics were encapsulated, that could 
probably be reduced. I'll think on it some more.
Cheers,
Mike

On 8/6/07, Michael Droettboom <md...@st...> wrote:
> 1) mathtext_example_default_hinting.png - Uses freetype's default
> hinting which uses hinting information in the file along with
> auto-hinting to get around some patents. This is what matplotlib was
> using when I got here.
I am still a bit confused here -- since the bakoma cm fonts presumably
include hinting, why is it so bad? Is it just that the hinting
information in them is not good, and some of the autohinting
approaches below are simply better? I initially thought the problem
was that they didn't include hinting...
> 2) mathtext_example_light.png - Uses freetype's "light" hinting.
To my eyes, the biggest problems are in plain roman text, eg \sin, and
I think 1 and 2 both fail this case pretty badly (eg example 10 in
your output). TO my eyes, no hinting looks better than light hinting
for these examples (and 4 is best)
> 3) mathtext_example_nohint.png - All hinting off.
>
> 4) mathtext_example_vert_hinting.png - This follows the suggestion in
> Maxim's article to hint only in the vertical direction. Since freetype
> doesn't support that natively, it uses a hack where you set the x-dpi to
> be much higher than the y-dpi, thereby hinting the x-direction to a much
I guess beauty is in the eye of the holder, but at screen resolution I
am not seeing too much difference in the italic 'i' and 'y'. But for
roman text, eg the "c" in "braces" in example 7 and "sin" in example
10, I think 3 and 4 are the best two, with 4 getting the nod.
If it is simply a case where the bakoma hinting is bad, and another
set of fonts with better hinting will solve the problem using default
hinting, we could opt to turn hinting off until we get a better set of
fonts. As for uglifying ft2font, presumably we could encapsulate the
ugliness into a helper class so we could say things like
o.get_metrics_unstretched() and o.get_metrics_stretched() and the rest
of the code would remain non-uglified..... But I'm just arm-chair
quarterbacking here....
JDH

On 8/6/07, Michael Droettboom <md...@st...> wrote:
> obscure and hackish to worry about the next time that code is modified.
> Are there plans to use Agg itself for font rendering in the future
> (and thereby push this issue downward?)
agg 2.5, and any enhancements Maxim makes to support fonts, will be
GPL and not usable by us, sadly.
JDH

Stefan van der Walt wrote:
> On Fri, Aug 03, 2007 at 03:13:01PM -0400, Michael Droettboom wrote:
>> On a related note, the Agg backend suffers a little bit from the lack of 
>> subpixel character placement. The spacing of symbols can look slightly 
>> incorrect because of that (since their placement is rounded to the 
>> nearest integer), particularly at the smaller sizes. I haven't gotten 
>> around to experimenting with rounding vs. truncating to see if that 
>> alone makes it look any better.
> 
> An interesting article by the author of AGG on the intricacies of font
> rendering:
> 
> http://antigrain.com/research/font_rasterization/index.html
Very illuminating read.
I've put the results of some of my own experiments up at:
	ftp://ftp.stsci.edu/tmp/mdroe
I've chosen to ignore subpixel anti-aliasing on LCD issue (aka 
ClearType) since you definitely wouldn't want that for a plot whose 
ultimate destination is a printer or even the web. (Besides, trying 
that out in matplotlib would require significant refactoring of ft2font 
to support color bitmaps internally.)
1) mathtext_example_default_hinting.png - Uses freetype's default 
hinting which uses hinting information in the file along with 
auto-hinting to get around some patents. This is what matplotlib was 
using when I got here.
2) mathtext_example_light.png - Uses freetype's "light" hinting.
3) mathtext_example_nohint.png - All hinting off.
4) mathtext_example_vert_hinting.png - This follows the suggestion in 
Maxim's article to hint only in the vertical direction. Since freetype 
doesn't support that natively, it uses a hack where you set the x-dpi to 
be much higher than the y-dpi, thereby hinting the x-direction to a much 
finer grid. When the glyph is copied from freetype's bitmap into 
matplotlib's bitmap, it is resampled back to the correct aspect ratio.
If you look at the examples, the character rendering differences are 
most pronounced, IMO, on the italic i's and y's. I think 3) looks the 
best and it is theoretically the most "accurate", but I imagine some 
will find it too blurry. Unfortunately, however, there are places where 
the lack of y-hinting make the text appear to have a wandering baseline 
(see #20 especially). 4) effectively solves that problem, at the 
expense of a hack.
I'm happy to commit the code for 4), however, I have reservations, since 
it really uglifies the code in ft2font.cpp. Once you start using 
freetype in "stretched space", all the metrics it returns etc. are also 
stretched and need to be unstretched when returning values to the caller 
(of ft2font). It isn't good enough to work in unstretched space and 
only stretch prior to rendering since the hinting causes the width of 
the glyphs to change based on the resolution of the grid they're being 
drawn on. It's not insurmountable (in fact I've already worked through 
most of the places where the division needs to occur), and it's 
completely hidden from *users* of ft2font, it just adds something fairly 
obscure and hackish to worry about the next time that code is modified. 
 Are there plans to use Agg itself for font rendering in the future 
(and thereby push this issue downward?)
Cheers,
Mike

On Fri, Aug 03, 2007 at 03:13:01PM -0400, Michael Droettboom wrote:
> On a related note, the Agg backend suffers a little bit from the lack o=
f=20
> subpixel character placement. The spacing of symbols can look slightly=
=20
> incorrect because of that (since their placement is rounded to the=20
> nearest integer), particularly at the smaller sizes. I haven't gotten=20
> around to experimenting with rounding vs. truncating to see if that=20
> alone makes it look any better.
An interesting article by the author of AGG on the intricacies of font
rendering:
http://antigrain.com/research/font_rasterization/index.html
Cheers
St=E9fan

Michael Droettboom <mdroe@...> writes:
> You're right. That's a bug that crept in. The other difference (that I 
> just noticed now), is that the \Delta is slanted, where it isn't in TeX. 
> The rules as to when a Greek character is italicized are a little 
> unclear to me. (Only when lowercase?)
Yes, that's the TeX rule. Wikipedia claims it to be the American convention:
http://en.wikipedia.org/wiki/Typographical_conventions_in_mathematical_formulae
-- 
Jouni

John Hunter wrote:
> Michael, I'm finally getting around to running the new mathtext
> examples in mathtext_examples.py. Wow.
> 
> As before, I noticed a few things that don't look quite right -- as
> usual, some of this may be bakoma font problems, and some may be
> correct but just look funny to me, but I'll mention them briefly
> 
> - r'$\Delta_i^j$' : the j looks too far to the right
You're right. That's a bug that crept in. The other difference (that I 
just noticed now), is that the \Delta is slanted, where it isn't in TeX. 
 The rules as to when a Greek character is italicized are a little 
unclear to me. (Only when lowercase?)
> - \frac and \sqrt overbar: the horizontal line appears too thick,
> can we make this thinner? THe look pretty good in PS, but too thick
> in Agg.
With Agg (and by extension Cairo) the lines are drawn as filled 
rectangles rounded to the nearest integral pixel coordinates in FT2Font, 
rather than by using the line drawing functionality of Agg. The planned 
backend refactorings will make that easier, but there's probably ways to 
make it work now, I just haven't gotten around to it.
On a related note, the Agg backend suffers a little bit from the lack of 
subpixel character placement. The spacing of symbols can look slightly 
incorrect because of that (since their placement is rounded to the 
nearest integer), particularly at the smaller sizes. I haven't gotten 
around to experimenting with rounding vs. truncating to see if that 
alone makes it look any better.
> The recursive frac examples are very cool!
> 
> - r"$\sqrt[3]{\frac{X_2}{Y}}=5$", I would think the Y should be
> under the X, but it is centered under the whole of X_2. Is this how
> TeX does it?
Yes, that's how TeX does it. If you're curious, you can run 
"mathtext_examples.py --latex", which will produce a LaTeX file of all 
the examples and run it through pdflatex. That's what I've been using 
as a point of comparison as I go. Things don't match up perfectly -- 
tweaking is still ongoing. In general, with tons of due respect to 
TeX/LaTeX, while it's a good goal to emulate it as close as possible, if 
there are some things that we can improve on (within the much narrower 
context of matplotlib), I don't think we should shy away. Personally, 
I'm more concerned with getting the *semantics* as equivalent as 
possible, rather than the actual results. That goes along with my 
general weariness of exposing too many low-level commands, as that's 
where the real differences in the implementations lie. (But I may be 
totally off-base on those assumptions... I'd like to hear from heavy 
mathtext users about that).
> - Hinting: you mentioned that the fonts looked so bad because they
> lacked hinting. Is this something entirely missing from the fonts or
> are we just not making use of it? With hinting, we would have a very
> serviceable set of fonts, at least until the STIX fonts come out in
> 2018
That's something I haven't looked into very deeply, and it was just 
conjecture based on the fact that the fonts look much more "even" at 
higher resolutions. I don't know if the disabled hinting bytecodes in 
freetype are the cause. It definitely warrants further investigation.
> - Kerning -- I may have mentioned this before. I have thought about
> implementing autokerning by using the ink extent of the renderered
> glyph in the freetype pixel buffer. This would enable us to properly
> kern sin(2\pi) for example, if the ) char is in a different font file
> than \pi. Over the vertical extent of the \pi, you could locate the
> left most pixel ink of the ')' and kern it to the left a bit. Do you
> think this is something worth doing, or do you have an alternative?
The cop-out answer is that TeX doesn't seem to do any kerning in math 
mode. Try the following: "AVA $AVA$", "({\it f}) $(f)$", for example. 
But that's not a reason to not do it.
That said, IMHO, we might get more mileage out of looking into ways to 
improve the low-level glyph rendering. The fonts look much better in 
acroread, for instance, than in ghostscript, with the same PDF file. 
Which leads me to believe it's not so much the quality of the font, but 
the rendering engine (or the way it's being used). I am not running the 
latest-and-greatest freetype2 library -- I don't know if that will make 
a difference.
The other thing that bothers me (but maybe not anyone else), is the font 
sizing. In TeX, when the font shrinks into a subscript, the characters 
get shorter, and the line widths stay relatively constant, rather than 
being uniformly scaled. The Bakoma fonts are actually available in a 
variety of sizes:
http://www.ctan.org/tex-archive/fonts/cm/ps-type1/bakoma/ttf/
so it is doable -- it's just a matter of writing the machinery that 
selects fonts based on the level of logical font size. It would mean 
distributing a lot more fonts with matplotlib, but with the font 
subsetting stuff working, it shouldn't have a significant impact on 
resulting file sizes.
> In the worst case scenario, one could use the spacing operators to fix
> stuff up manually for publication, I suppose.
True.
Cheers,
Mike

Michael, I'm finally getting around to running the new mathtext
examples in mathtext_examples.py. Wow.
As before, I noticed a few things that don't look quite right -- as
usual, some of this may be bakoma font problems, and some may be
correct but just look funny to me, but I'll mention them briefly
 - r'$\Delta_i^j$' : the j looks too far to the right
 - \frac and \sqrt overbar: the horizontal line appears too thick,
can we make this thinner? THe look pretty good in PS, but too thick
in Agg.
The recursive frac examples are very cool!
 - r"$\sqrt[3]{\frac{X_2}{Y}}=5$", I would think the Y should be
under the X, but it is centered under the whole of X_2. Is this how
TeX does it?
 - Hinting: you mentioned that the fonts looked so bad because they
lacked hinting. Is this something entirely missing from the fonts or
are we just not making use of it? With hinting, we would have a very
serviceable set of fonts, at least until the STIX fonts come out in
2018
 - Kerning -- I may have mentioned this before. I have thought about
implementing autokerning by using the ink extent of the renderered
glyph in the freetype pixel buffer. This would enable us to properly
kern sin(2\pi) for example, if the ) char is in a different font file
than \pi. Over the vertical extent of the \pi, you could locate the
left most pixel ink of the ')' and kern it to the left a bit. Do you
think this is something worth doing, or do you have an alternative?
In the worst case scenario, one could use the spacing operators to fix
stuff up manually for publication, I suppose.
Anyway, very nice work.
JDH

John Hunter wrote:
> Hi Michael,
> 
> I just tried building mpl from svn at work for the first time since
> your changes, and wanted to let you know about a use case that isn't
> convered by your checks. We build mpl by passing in -I and other
> args, eg in a Makefile:
> 
> 	cd ${SRCDIR}/matplotlib/matplotlib; CC=${CC} CXX=${CXX}
> PKG_CONFIG_PATH=${PKG_CONFIG_PATH}
> PYTHONPATH=${INSTALL_LOCAL}:/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/3rdParty/gtk-2.6
> python setup.py build_ext -I
> /opt/app/gnome-2.6/include:/opt/app/libpng/include:/opt/app/freetype-2.1.10/include:/opt/app/freetype-2.1.10/include/freetype2
> -L /opt/app/gnome-2.6/lib:/opt/app/libpng/lib:/opt/app/freetype-2.1.10/lib
> -R /opt/app/gnome-2.6/lib:/opt/app/freetype-2.1.10/lib:/opt/app/libpng/lib
> build
> and your freetype include checker is not finding ft2build.h and
> failing, although the build process finds it. I can simply comment
> out the return False in the include file checker and get the thing to
> build, but I wonder if we can handle this case, or if not perhaps we
> should simply warn but not fail.
Ah, I see. Yes, I'll turn the check into a warning. My main motivation 
was to make it more obvious why the build was failing when freetype 
couldn't be found (and to use pkg-config to look for freetype2 when 
possible). But you're right, you can't cover all the cases that way.
> Also, in the libpng check, I think you put the comma join in the wrong
> place. Did you mean
> 
> print_message(
> "Could not find 'libpng' headers in any of %s" %
> ', '.join(["'%s'" % x for x in module.include_dirs]))
Yes, thanks.
Cheers,
Mike

Hi Michael,
I just tried building mpl from svn at work for the first time since
your changes, and wanted to let you know about a use case that isn't
convered by your checks. We build mpl by passing in -I and other
args, eg in a Makefile:
	cd ${SRCDIR}/matplotlib/matplotlib; CC=${CC} CXX=${CXX}
PKG_CONFIG_PATH=${PKG_CONFIG_PATH}
PYTHONPATH=${INSTALL_LOCAL}:/opt/app/g++lib6/python-2.4/lib/python2.4/site-packages/3rdParty/gtk-2.6
python setup.py build_ext -I
/opt/app/gnome-2.6/include:/opt/app/libpng/include:/opt/app/freetype-2.1.10/include:/opt/app/freetype-2.1.10/include/freetype2
 -L /opt/app/gnome-2.6/lib:/opt/app/libpng/lib:/opt/app/freetype-2.1.10/lib
 -R /opt/app/gnome-2.6/lib:/opt/app/freetype-2.1.10/lib:/opt/app/libpng/lib
build
and your freetype include checker is not finding ft2build.h and
failing, although the build process finds it. I can simply comment
out the return False in the include file checker and get the thing to
build, but I wonder if we can handle this case, or if not perhaps we
should simply warn but not fail.
Also, in the libpng check, I think you put the comma join in the wrong
place. Did you mean
 print_message(
 "Could not find 'libpng' headers in any of %s" %
 ', '.join(["'%s'" % x for x in module.include_dirs]))

Darren Dale wrote:
[...]
> 
> How about markup="TeX" then?
"markup" is a good kwarg for this; it is descriptive and won't be 
confused with anything else.
Eric
> 
>> And yes, having a rcoption default seems like it could be handy.
> 

Hi,
 I wonder if there is any example to copy a line belong to one figure 
to another figure?
Thanks
Xuedong

On Thursday 02 August 2007 11:03:09 am Michael Droettboom wrote:
> Darren Dale wrote:
> > On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
> >> On 8/2/07, Michael Droettboom <md...@st...> wrote:
> >>> I don't know if we ever reached consensus on how to specify math text
> >>> vs. regular text. I agree with Eric that it's down to two options:
> >>> using a new kw argument (probably format="math" to be most
> >>> future-proof) or Math('string'). I don't think I have enough
> >>> "historical perspective" to really make the call but I do have a
> >>> concern about the second option that it may be confusing depending on
> >>> how "Math" is imported. (It may have to be pylab.Math in some
> >>> instances but not in others.) But I don't have a strong objection.
> >>>
> >>> Any last objections to going with the new keyword argument?
> >>
> >> I'm +1 on the kwarg approach -- it seems most consistent with our other
> >> usage.
> >
> > Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it
> > would be appropriate to have the kwarg default to None, and if None
> > reference an rcoption like text.texformatting? That might be the least
> > disruptive all around.
>
> I think format="TeX" may be a bit misleading, since it uses something
> TeX-like, but not really TeX (as the usetex stuff does). That said, I
> don't really have a better suggestion ;)
>
> The idea also is that in the future this could support other values,
> e.g. format="html" might support "<b>bold</b>" for instance, so
> texformatting=True would be less extensible overall.
How about markup="TeX" then?
> And yes, having a rcoption default seems like it could be handy.

Darren Dale wrote:
> On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
> 
>> On 8/2/07, Michael Droettboom <md...@st...> wrote:
>> 
>>> I don't know if we ever reached consensus on how to specify math text
>>> vs. regular text. I agree with Eric that it's down to two options:
>>> using a new kw argument (probably format="math" to be most future-proof)
>>> or Math('string'). I don't think I have enough "historical perspective"
>>> to really make the call but I do have a concern about the second option
>>> that it may be confusing depending on how "Math" is imported. (It may
>>> have to be pylab.Math in some instances but not in others.) But I don't
>>> have a strong objection.
>>>
>>> Any last objections to going with the new keyword argument?
>>> 
>> I'm +1 on the kwarg approach -- it seems most consistent with our other
>> usage.
>> 
>
> Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it 
> would be appropriate to have the kwarg default to None, and if None reference 
> an rcoption like text.texformatting? That might be the least disruptive all 
> around.
> 
I think format="TeX" may be a bit misleading, since it uses something 
TeX-like, but not really TeX (as the usetex stuff does). That said, I 
don't really have a better suggestion ;)
The idea also is that in the future this could support other values, 
e.g. format="html" might support "<b>bold</b>" for instance, so 
texformatting=True would be less extensible overall.
And yes, having a rcoption default seems like it could be handy.
Cheers,
Mike

On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
> On 8/2/07, Michael Droettboom <md...@st...> wrote:
> > I don't know if we ever reached consensus on how to specify math text
> > vs. regular text. I agree with Eric that it's down to two options:
> > using a new kw argument (probably format="math" to be most future-proof)
> > or Math('string'). I don't think I have enough "historical perspective"
> > to really make the call but I do have a concern about the second option
> > that it may be confusing depending on how "Math" is imported. (It may
> > have to be pylab.Math in some instances but not in others.) But I don't
> > have a strong objection.
> >
> > Any last objections to going with the new keyword argument?
>
> I'm +1 on the kwarg approach -- it seems most consistent with our other
> usage.
Maybe the keyword should be format="TeX"? Or texformatting=True? Maybe it 
would be appropriate to have the kwarg default to None, and if None reference 
an rcoption like text.texformatting? That might be the least disruptive all 
around.
Darren

On 8/2/07, Michael Droettboom <md...@st...> wrote:
> I don't know if we ever reached consensus on how to specify math text
> vs. regular text. I agree with Eric that it's down to two options:
> using a new kw argument (probably format="math" to be most future-proof)
> or Math('string'). I don't think I have enough "historical perspective"
> to really make the call but I do have a concern about the second option
> that it may be confusing depending on how "Math" is imported. (It may
> have to be pylab.Math in some instances but not in others.) But I don't
> have a strong objection.
>
> Any last objections to going with the new keyword argument?
I'm +1 on the kwarg approach -- it seems most consistent with our other usage.

I don't know if we ever reached consensus on how to specify math text 
vs. regular text. I agree with Eric that it's down to two options: 
using a new kw argument (probably format="math" to be most future-proof) 
or Math('string'). I don't think I have enough "historical perspective" 
to really make the call but I do have a concern about the second option 
that it may be confusing depending on how "Math" is imported. (It may 
have to be pylab.Math in some instances but not in others.) But I don't 
have a strong objection.
Any last objections to going with the new keyword argument?
Cheers,
Mike
Eric Firing wrote:
> That leaves some variant of 2 [a keyword argument] and the Math('string') idea. I find the 
> latter quite pythonic; it is a very concise, readable, and general way 
> of attaching extra information to a string object, and it does not 
> require passing yet another kwarg through a sequence of function and 
> method calls. But if it is judged to be too out-of-character with the 
> rest of the mpl api, or if in practice it would cause trouble that I 
> don't see yet, then I am happy to let it go. I have not thought it 
> through carefully, and I am not attached to it.
>
> If a variant of 2 is chosen, one might shorten the kwarg to "math". Or 
> use "format='math'" or something like that. This is more flexible than 
> a boolean kwarg, leaving the door open to additional options for 
> interpretation of strings--but not quite as flexible and powerful as the 
> math('string') idea.
> 

Fernando,
Here is some more information about profiling that others may find useful:
1) The profile module reports times that are much longer than normal; I 
don't know to what extent the relative times are still correct; my 
impression is that they do still give a decent idea of where the 
bottlenecks and resource hogs are.
2) The combination of hotshot and hotshot2calltree (or similar) gets 
badly confused by duplicate function names such as __init__, so the 
kcachegrind view can be quite misleading.
3) A solution is to use the cProfile module in Python 2.5 with an 
appropriate reformatter. The following script runs a python script 
through cProfile and generates a *.log file that kcachegrind reads:
http://www.gnome.org/~johan/lsprofcalltree.py
So the sequence is simply
python lsprofcalltree.py testscript.py
kcachegrind testscript.py.log &
Here are a couple of relevant Google results:
https://lists.dulug.duke.edu/pipermail/yum-devel/2007-January/003045.html
http://ddaa.net/blog/python/lsprof-calltree
Eric
Fernando Perez wrote:
> On 7/31/07, Darren Dale <dd...@co...> wrote:
> 
>> I am attaching the results for two different tests. One is loading the default
>> mpl-data/matplotlib.conf, the other is loading an empty
>> ~/.matplotlib/matplotlib.conf. I haven't done much work with profiling, maybe
>> others can make some comments about the results.
> 
> I'm afraid I can't help with this right now, but you may want to look at
> 
> http://amath.colorado.edu/faculty/fperez/python/profiling/
> 
> the little code I put in there makes using kcachegrind very easy for
> python profiling, and it's really a useful tool for analyzing
> profiling info.
> 
> Cheers,
> 
> f

Michael Droettboom wrote:
> I suspect you're running an earlier version of pygtk than I am that
> doesn't have pygobject_version.
>
> Please update matplotlib and try again.
>
> Thanks for finding this bug.
>
> Cheers,
> Mike
>
> Nils Wagner wrote:
>> Hi all,
>>
>> I cannot build matplotlib from latest svn. I am using SuSE Linux 10.0 on
>> x86_64.
>>
>> python setup.py install
>> ============================================================================
>>
>> BUILDING MATPLOTLIB
>> matplotlib: 0.90.1 (r3634)
>> platform: linux2
>>
>> REQUIRED DEPENDENCIES
>> numpy: 1.0.4.dev3937
>> freetype2: 9.8.3
>>
>> OPTIONAL DEPENDENCIES
>> Traceback (most recent call last):
>> File "setup.py", line 223, in ?
>> if check_for_gtk() and (BUILD_GTK or BUILD_GTKAGG):
>> File "/usr/local/svn/matplotlib/setupext.py", line 411, in
>> check_for_gtk
>> print_status("Gtk+", "gtk+: %s, glib: %s, pygtk: %s, pygobject:
>> %s" %
>> AttributeError: 'module' object has no attribute 'pygobject_version'
>>
>> Nils
>>
>>
>>
>> -------------------------------------------------------------------------
>>
>> 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
>> 
>
Mike,
Thank you for your prompt reply ! Now it works for me.
Cheers,
 Nils
BTW, I am using
rpm -qi python-gtk
Name : python-gtk Relocations: (not relocatable)
Version : 2.8.0 Vendor: SUSE LINUX
Products GmbH, Nuernberg, Germany
Release : 3 Build Date: Tue 13 Sep 2005
02:56:46 AM CEST
Install date: Mon 27 Feb 2006 11:04:09 AM CET Build Host:
mahler.suse.de
Group : Development/Libraries/Python Source RPM:
python-gtk-2.8.0-3.src.rpm
Size : 5041273 License: LGPL
Signature : DSA/SHA1, Tue 13 Sep 2005 04:32:38 AM CEST, Key ID
a84edae89c800aca
Packager : http://www.suse.de/feedback
URL : http://www.pygtk.org/
Summary : Python bindings for the GTK+ widget set
Description :
PyGTK is an extension module for python that gives you access to the
GTK+ widget set. Just about anything you can write in C with GTK+ you
can write in python with PyGTK (within reason), but with all of
python's benefits.
Authors:
--------
 James Henstridge <ja...@da...>
Distribution: SUSE LINUX 10.0 (X86-64)
 

I suspect you're running an earlier version of pygtk than I am that 
doesn't have pygobject_version.
Please update matplotlib and try again.
Thanks for finding this bug.
Cheers,
Mike
Nils Wagner wrote:
> Hi all,
>
> I cannot build matplotlib from latest svn. I am using SuSE Linux 10.0 on
> x86_64.
>
> python setup.py install
> ============================================================================
> BUILDING MATPLOTLIB
> matplotlib: 0.90.1 (r3634)
> platform: linux2
>
> REQUIRED DEPENDENCIES
> numpy: 1.0.4.dev3937
> freetype2: 9.8.3
>
> OPTIONAL DEPENDENCIES
> Traceback (most recent call last):
> File "setup.py", line 223, in ?
> if check_for_gtk() and (BUILD_GTK or BUILD_GTKAGG):
> File "/usr/local/svn/matplotlib/setupext.py", line 411, in check_for_gtk
> print_status("Gtk+", "gtk+: %s, glib: %s, pygtk: %s, pygobject: %s" %
> AttributeError: 'module' object has no attribute 'pygobject_version'
>
> Nils
>
>
>
> -------------------------------------------------------------------------
> 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
>