Eric Firing wrote:
> So, this test is still showing problems, with similar memory
> consumption in these three backends.
Not necessarily. By default, Python allocates large pools from the
operating system and then manages those pools itself (though its
PyMalloc call). Prior to Python 2.5, thos
ead I get dozens of windows open at
once. Is that a known bug or correct behavior?
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Eric Firing wrote:
>>> So, this test is still showing problems, with similar memory
>>> consumption in these three
Forgot to attach the patches.
Oops,
Mike
Michael Droettboom wrote:
More results:
I've built and tested a more recent pygtk+ stack. (glib-2.12,
gtk+-2.10.9, librsvg-2.16.1, libxml2-2.6.29, pygobject-2.13.1,
pygtk-2.10.4...). The good news is that the C-level leaks I was seeing
in
John Hunter wrote:
> On 7/2/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>> Forgot to attach the patches.
>
> Michael -- if you send me your sf ID I'll add you to the committers
> list and you can check these in directly.
mdboom
> Vis-a-vis the gtk question,
Eric Firing wrote:
> I also made memleak_gui.py more flexible with arguments. For example,
> here are tests with three backends, a generous number of loops, and
> suppression of intermediate output:
Those changes are really helpful. I just added code to display the
total number of objects in t
Eric Firing wrote:
>
> I just committed a change to the output formatting of memleak_gui so
> that if you redirect it to a file, that file can be loaded with
> pylab.load() in case you want to plot the columns. (At least this is
> true if you don't use the -c option.)
>
Great. Sorry for stompi
Eric Firing wrote:
Attached are runs with gtk, wx, qtagg, and tkagg. Quite a variety of
results: tkagg is best, with only slow memory growth and a constant
number of python objects; qtagg grows by 2.2k per loop, with no
increase in python object count; wx (which is built on gtk) consumes
3.5k
[I've been discussing this off-list with John Hunter, and I thought I'd
summarize that conversation in case anyone else on this list has any
thoughts or suggestions.]
I've started working on the problem of reducing Postscript output file
sizes by saving out only the glyphs that are used in the
Eric Firing wrote:
> Michael Droettboom wrote:
>> 1. Subset the Truetype font into another Truetype font and embed it
>> as we do now. This could theoretically be done with fonttools/ttx.
>> Writing out .ttf files looks to be rather complex, and there's a lot
>
Yes -- the global wxapp variable was removed (a very good thing). I
just committed a patch to fix this crash (r3460)
Cheers,
Mike
Christopher Barker wrote:
> Eric Firing wrote:
>
>> I just updated from svn and tried to rerun the wx test, but ran into an
>> error:
>>
>> [EMAIL PROTECTED]:~/p
Carl Worth wrote:
> You might take a look at what kind of PostScript and PDF output you
> get from cairo right now, (since cairo has many different kinds of
> font subsetting, (type3, type42 and others), and it's regularly being
> tested on as many PostScript and PDF viewers as possible).
>
Than
Michael Droettboom wrote:
> Carl Worth wrote:
>
>> You might take a look at what kind of PostScript and PDF output you
>> get from cairo right now, (since cairo has many different kinds of
>> font subsetting, (type3, type42 and others), and it's regularly being
&g
Interesting. I don't get that, but I do get some random segfaults (I
got lucky the first time I tested).
I'm awfully surprised that wx.GetApp() would return an iterator, as you
are getting, so maybe it's corruption of some sort?
Reverting to revision 3441 on backend_wx.py does resolve this iss
John Hunter wrote:
> On 7/5/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> It may be worthwhile to look at Cairo's font subsetting code if it's
>> determined that the Python Postscript backend has other advantages. I'm
>> sure people who'v
what type of
object is being leaked, which is a good first step.
If that doesn't make it immediately obvious, I'll try this on my Ubuntu
box at home and see if I can reproduce what you're seeing.
Cheers,
Mike
Eric Firing wrote:
Michael Droettboom wrote:
Interesting. I don&#x
John Hunter wrote:
> On 7/5/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>
>> Do you agree that it is still an open question whether it's better to
>> spend time improving the matplotib PS backend, or to fix (if possible)
>> the issues with ma
Yep. Nothing obvious. I'll have to have a look on Ubuntu and see if
that makes a difference.
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script?
>> This i
That is at least something to go by. ;)
Thanks,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script?
>> This is how I was finding object leaks before. It takes a single
>
Carl Worth wrote:
>> don't think it is supported in cairo. So I am not sure where these
>> rasters are coming from, unless cairo is converting all text to
>> rasters.
>>
>
> Definitely not converting all text to raster, (unless someone's using
> an ancient version of cairo).
>
I don't know
maintenance release. Promisingly, my bug was confirmed within about
five minutes of filing it.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381
<https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381>
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
maintenance release. Promisingly, my bug was confirmed within about
five minutes of filing it.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381
<https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381>
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
maintenance release. Promisingly, my bug was confirmed within about
five minutes of filing it.
https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381
<https://bugs.launchpad.net/ubuntu/+source/wxwidgets2.8/+bug/124381>
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
ers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script?
>> This is how I was finding object leaks before. It takes a single
>> commandline argument that is the number of it
My sincere apologies for the multiple copies of the e-mail sent this
morning. I was getting "SMTP server down" messages, but clearly the
messages were sent anyway.
I'm not a spammer, really! ;)
Mike
-
This SF.net email is
ers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script?
>> This is how I was finding object leaks before. It takes a single
>> commandline argument that is the number of it
et/ubuntu/+source/wxwidgets2.8/+bug/124381
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script?
>> This is how I was finding object leaks before. It takes a single
>&g
et/ubuntu/+source/wxwidgets2.8/+bug/124381
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script?
>> This is how I was finding object leaks before. It takes a single
>&g
ers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Interesting...
>>
>> When you get a chance, would you mind running the attached script?
>> This is how I was finding object leaks before. It takes a single
>> commandline argument that is the number of it
John Hunter wrote:
> On 7/6/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> I don't know the root cause, but FYI I'm definitely getting rasterized
>> text with the Cairo backend for mathtext_demo.py. (I'm using
>> cairo-1.4.10, which I believe i
John Hunter wrote:
> What about simple_demo.py -- do you get rasters there too?
No. I get vectors there.
I noticed that using the backend "GtkCairo" seems to use backend_ps.py
for Postscript output. Using backend "Cairo" uses cairo. Maybe
probably explains the difference between Darren and my
You're right: my bad. Should be fixed in r3461.
Cheers,
Mike
Eric Firing wrote:
> Mike,
>
> When I try to save a file as postscript using the FileChooserDialog
> with GtkAgg, I get:
>
> [EMAIL PROTECTED]:~/programs/py/mpl/matplotlib_units/examples$ python
> quadmesh_demo.py
> Traceback (most r
Michael Droettboom wrote:
> You're right: my bad. Should be fixed in r3461.
>
I meant to type r3484.
> Cheers,
> Mike
>
> Eric Firing wrote:
>
>> Mike,
>>
>> When I try to save a file as postscript using the FileChooserDialog
>> with GtkAgg
plicate matplotlib code for the sake of something that should
resolve itself in the next Gnome release cycle...
I updated the memleak_gui.py script to display the pygobject/glib
versions as well when testing the gtk backend.
Cheers,
Mike
Michael Droettboom wrote:
> Eric Firing wrote
I am about to update the memory leak question in the FAQ, but I thought
I'd run it by the list first. I removed language that talked about much
earlier releases of mpl, and the paragraph about leaks in older versions
of Numeric and numarray. It seems like we should recommend numpy when
the us
An initial revision of TTF font subsetting has been committed to SVN.
It seems to work for all tests run by backend_driver.py (with the
exception quiver_demo, which didn't seem to work without my changes either).
Some key results:
fonts_demo_kq_ps.py: 633518 -> 45232
mathtext_demo.py: 366268 -
Sorry about that. I didn't notice the SVN login error the first time.
It should be in SVN now.
The default is to output Type 3 fonts (i.e. the new way).
Darren: you mean rcdefaults.py, not rcsetup.py, right? I can't find an
rcsetup.py.
Cheers,
Mike
John Hunter wrote:
> On 7/9/07, Darren D
Eric Firing wrote:
> Michael Droettboom wrote:
>> Sorry about that. I didn't notice the SVN login error the first
>> time. It should be in SVN now.
>> The default is to output Type 3 fonts (i.e. the new way).
>>
>> Darren: you mean rcdefaults.py, not r
More data points are welcome.
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
> [...]
>> All should be in SVN.
>
> Mike,
>
> Now it compiles and runs all the demos, and displays OK at normal
> resolution; but when I try to show it with gv or evince at 40
on my Ubuntu box at home, since building all
that on this RHEL4 box could be time consuming.
Does the following work for you?
gs -sOUTPUT_DEVICE=pngalpha -sOutputFile=test%03d.png -r1200x1200
simple_plot_ps.ps
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Oh de
Eric Firing wrote:
> Michael Droettboom wrote:
>> Even if my Postscript is to spec, it's not terribly useful if it
>> crashes a very popular tool ;)
>>
>> I'm curious -- does the file fail if you set "ps.fonttype: 42" in
>> your matplotlibr
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
>> Here's simple_plot.ps generated with the old PS backend.
>
> Crash! Again, with 400% magnification. So now you really are off the
> hook.
>
> [EMAIL PROTECTED]:~/programs/py/mpl/tests$ e
I just committed changes that add TTF subsetting to the PDF backend. It
is completely analogous to the font subsetting recently added to the PS
backend.
I have added a configuration option, pdf.fonttype, to choose either
"Type3" or "Truetype" font output. This may be removed in the future
on
John Hunter wrote:
> On 7/10/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>>
>> fonts_demo_kw.py: 201744 -> 37326
>> mathtext_demo.py: 129306 -> 26179
>> unicode_demo.py: 45303 -> 20084
>> over all demos in backend_driver.py: 5856001 -> 33
Has anyone looked into embedding fonts in SVG files? That might
alleviate some of the installation problems that were recently mentioned
on the matplotlib-users list.
The relevant spec:
http://www.w3.org/TR/SVG11/fonts.html
If there are no plans under way, I may have a crack at it, since I'm
John Hunter wrote:
> On 7/10/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>> Has anyone looked into embedding fonts in SVG files?
>
> It's definitely come up before. Paul Barret may have had a look at
> it. I'm not sure why we ended up not doing it. You ca
Eric Firing wrote:
> I second that! I greatly appreciate your contributions, first in
> chasing down memory leaks and now in reducing file sizes by embedding
> fonts.
It's been fun.
Now, Eric, I'm just waiting for you to tell me how this latest batch
reveals another bug on Ubuntu ;) (with all
Jouni K. Seppänen wrote:
> "John Hunter" <[EMAIL PROTECTED]> writes:
>
>
>> On 7/10/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>>
> I'm seeing a bug on OS X, whose file system is by default
> case-preserving but not case
I'll commit this code once it's cleaned up and better tested etc. if
it's agreed this is something we want to do. I think in any case this
should be optional -- it gives the file some portability at the expense
of editability.
Cheers,
Mike
Carl Worth wrote:
> On
should be optional -- it gives the file some portability at the expense
> of editability.
>
> Cheers,
> Mike
>
> Carl Worth wrote:
>
>> On Tue, 10 Jul 2007 13:43:49 -0400, Michael Droettboom wrote:
>>
>>
>>> "major SV
Michael Droettboom wrote:
> Jouni K. Seppänen wrote:
>
>> "John Hunter" <[EMAIL PROTECTED]> writes:
>>
>>
>>
>>> On 7/10/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>>>
>>>
>> I&#x
Eric,
Thanks for the scripts -- they make it quite clear what the problem is.
As you know, cntr.c is a fairly opaque chunk of code, and I'm not having
much luck so far tracking down why the branch-cutting between the outer
and inner polygons is not working.
In the meantime, I have some more ge
Michael Droettboom wrote:
> cntr.c is creating the inner and outer
> polygons correctly, just not connecting them with a slit, right?
>
To answer my own question, unfortunately, this isn't always the case.
There is also a bug where if a masked region is inside of the *inner*
FWIW, I'm able to reproduce this here. I have a hunch it may be related
to my recent Tk memory leak "improvements". I'll look into this further
and get back soon.
Cheers,
Mike
John Hunter wrote:
> On 7/13/07, Rob Hetland <[EMAIL PROTECTED]> wrote:
>
>> Nope -- the same occurs in the regula
agg.cpp), so that if we get ourselves into that situation again,
we'll get a Python exception rather than a segfault.
If you still see crashes with the Qt backend, also let us know. This
fix doesn't affect Qt at all.
Cheers,
Mike
Michael Droettboom wrote:
> FWIW, I'm able to r
As a stopgap measure until someone with more knowledge of these changes
replies, the following worked for me. In setup.py, uncomment the old
distutils import, and comment the new setuptools import:
#from distutils.core import Extension, setup
from setuptools import setup
to
from distutils.cor
Darren Dale wrote:
> If not, should we use
> u'\xd7' or '×' in the actual sources (the latter requiring the file's
> encoding to be declared at the beginning of the file, like: # -*- coding:
> utf-8 -*-)?
In an ideal world, I would prefer the latter, but we would want to
verify that all the mat
I'm working on some improvements to the mathtext engine on a branch.
Feel free to join in if curious, but I expect to break lots of things as
I go.
https://matplotlib.svn.sourceforge.net/svnroot/matplotlib/branches/mathtext_mgd/
I've collected a bunch of math expressions from the source tree f
Eric Firing wrote:
> While you are at it, perhaps you can figure out how to stop
> unicode_demo from generating an error:
>
> driving unicode_demo.py
> File "_tmp_unicode_demo.py", line 10
> SyntaxError: Non-ASCII character '\xe9' in file _tmp_unicode_demo.py
> on line 10, but no encodi
John Hunter wrote:
> On 7/16/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>> I'm working on some improvements to the mathtext engine on a branch.
>> Feel free to join in if curious, but I expect to break lots of things as
>> I go.
>>
>> ht
Gael Varoquaux wrote:
> On Mon, Jul 16, 2007 at 10:31:03PM -0500, John Hunter wrote:
>
>> I am happy to be the first at this point -- enthought has done a lot
>> to support traits. Traits has one of the most impressive pieces of
>> technical documentation in the scientific python community.
>>
--- Begin Message ---
Python 2.5 changed encodings.cp1252.decoding_map to a decoding_table.
There is a fix for this in matplotlib SVN. See this bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1738494&group_id=80706&atid=560720
You should be able to use the patch to fix your lo
Ken McIvor wrote:
>> This means someone needs to figure out how to get TkInter talking to
>> a python
>> buffer object or a numpy array.
>
> I think PIL's ImageTk module would do the trick for converting RGBA ->
> PIL Image -> Tk Bitmap/PhotoImage.
That's what I was thinking, too. I don't think
Ken McIvor wrote:
> On Jul 20, 2007, at 6:26 AM, Michael Droettboom wrote:
>> Ken McIvor wrote:
>>>>
>>> I think PIL's ImageTk module would do the trick for converting RGBA ->
>>> PIL Image -> Tk Bitmap/PhotoImage.
>>
>> That'
Gael Varoquaux wrote:
> On Sat, Jul 21, 2007 at 05:50:19PM -0400, Xuedong Zhang wrote:
>
>> What I am trying to run is the following command:
>>
>
>
>> sudo checkinstall python setup.py install
>>
>
>
>> I guess this maybe the problem between checkinstall and matplotlib
>>
>
I suspect my recent mathtext changes will help with Paul's problem.
I should probably give a quick update -- I've been coding pretty
experimentally lately and didn't want to report on too much if I was
likely to back it out later.
I've implemented a fairly direct Python translation of the TeX b
Chris Barker wrote:
> Peter Wang wrote:
>
>>> Ah! and some good math implementation -- What does Chaco do for
>>> that?
>>>
>
>
>> We've also had this discussion internally a bit. It usually
>> concludes with us wishing that someone would just port jsmath to
>> Python, or implem
The new mathtext with an underlying TeX-like box model is passing all
unit tests for all backends. I'm now at a point where I'd like to merge
this back into the trunk, but I'd like some feedback as to how to best
deal with the backward-incompatible change wrt font changes.
(This was discussed
John Hunter wrote:
> On 7/25/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> It's been fun working through this. You may want to check out
>> mathtext_examples.py in my branch for examples that exercise other new
>> features.
>
> Maybe you haven
John Hunter wrote:
> On 7/25/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>> The new mathtext with an underlying TeX-like box model is passing all
>> unit tests for all backends. I'm now at a point where I'd like to merge
>> this back into the trunk, bu
Gael Varoquaux wrote:
> On Fri, Jul 27, 2007 at 08:38:49AM -0400, Michael Droettboom wrote:
>
>>> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>>>
>
>
>> Except for the backward incompatibility, I like this because it is ex
John Hunter wrote:
> Option 1 is to educate them, and require them to \$
> quote that symbol. Option 2 is to enable a text property eg mathtext,
> and do
>
> text(x, y, 'what is the $\sin(x)$', mathtext=True)
>
Except for the backward incompatibility, I like this because it is explicit.
> Optio
Darren Dale wrote:
> I ran backend_driver with the traited config enabled, and the only errors I
> got were related to broken mathtext support in backend_svg, and I think those
> are unrelated to my changes.
>
I think I broke that for a few hours this morning, but it's working for
me now. N
Darren Dale wrote:
> On Monday 30 July 2007 03:33:11 pm you wrote:
>
>> Darren Dale wrote:
>>
>>> I ran backend_driver with the traited config enabled, and the only errors
>>> I got were related to broken mathtext support in backend_svg, and I think
>>> those are unrelated to my changes.
>>
Eric Firing wrote:
> I don't have a lot of experience with profiling...
Slightly OT, but I do have a recommendation for anyone doing Python
profiling. I don't usually get very excited about GUI tools, but
KCachegrind (Linux only) is very slick and works great with Python.
It's really handy to
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_
Darren Dale wrote:
> On Thursday 02 August 2007 10:42:17 am John Hunter wrote:
>
>> On 8/2/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>>
>>> I don't know if we ever reached consensus on how to specify math text
>>> vs. regular text.
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 m
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}/matp
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
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
John Hunter wrote:
> On 8/6/07, Michael Droettboom <[EMAIL PROTECTED]> 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. T
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
y highly specialized. I don't think that approach is
necessary or desirable here.
I suppose my initial disappointment in SWIG is that I like its
fundamental idea -- of automating the tedious boilerplate -- but the
execution of it just seems so heavyweight. But maybe that doesn't
re
I just finished writing code to support scalable mathtext with the Cairo
backend. (The old version rendered the mathtext to bitmaps first).
Mostly straightforward, but I ran into one small snag. It *seems* that
pycairo requires that the fonts it uses are installed and accessible
through fontconf
Christopher Barker wrote:
>> http://www.artima.com/weblogs/viewpost.jsp?thread=95863
>
> Thanks
>> (It was in Mike's original message.)
>
> I must have missed that. Guido says:
>
> """
> I've yet to see an extension module using SWIG that doesn't make me
> think it was a mistake to use SWIG ins
Eric Firing wrote:
> Michael Droettboom wrote:
>> I appreciate the way it fits so nicely into C++ ideas about RAII and
>> exceptions -- but if you're not a C++ guy, that pro is probably a con.
> What is RAII?
"Resource Aquisition is Initialization" -- It
Just wanted to link up this thread with a question I posed on the cairo
mailing list.
http://lists.cairographics.org/archives/cairo/2007-August/011201.html
Cheers,
Mike
Eric Firing wrote:
> Michael Droettboom wrote:
> [...]
>> One middle ground I thought of since my first messa
Rob Hetland wrote:
>
> On Aug 6, 2007, at 4:03 PM, Michael Droettboom wrote:
>> There is now experimental support for custom fonts in math mode.
>> Try the above, and let me know how it goes...
>
> I finally had time to try out your new code a bit, and I like it. It
&
e. It's always hard to
weigh those tradeoffs.
Cheers,
Mike
Michael Droettboom wrote:
> Just wanted to link up this thread with a question I posed on the cairo
> mailing list.
>
> http://lists.cairographics.org/archives/cairo/2007-August/011201.html
>
> Cheers,
>
Rob Hetland wrote:
>
> On Aug 6, 2007, at 4:03 PM, Michael Droettboom wrote:
>> There is now experimental support for custom fonts in math mode.
>> Try the above, and let me know how it goes...
>
> I finally had time to try out your new code a bit, and I like it. It
&
Michael Droettboom wrote:
> Rob Hetland wrote:
>> On Aug 6, 2007, at 4:03 PM, Michael Droettboom wrote:
>> I have been thinking that it might be possible to use some of the CM
>> sans fonts, like CM bright. Also, there is a Arev font set (vera,
>> backwards -- basical
Hmm... I'm not readily able to reproduce this here.
What are you setting in matplotlibrc (or in your plot?)
Also, if you delete the font cache (which is now
~/.matplotlib/fontManager.cache), does that help? (Might be a useful
data point -- not suggesting it as a solution.)
Cheers,
Mike
Rob
Thanks for fixing that. I haven't been running with the new traits config
stuff, so I didn't catch that my new parameters weren't ported over.
Cheers,
Mike
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping thr
Fernando Perez wrote:
> Hi all,
>
> here's a small patch for two little things I saw today:
>
> 1. The new mathtext has some unicode in it and on my system, python2.5
> was throwing a syntax error due to the lack of an encoding
> declaration. I just stuck utf-8 though I don't know if that's real
John Hunter wrote:
> On 8/20/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
>
>> UTF-8 is my default system encoding, so I didn't catch this. I just
>> fixed the comment (the unicode character is unnecessary to get the point
>> across and wasonly in th
Sorry for taking so long to respond -- I was at SciPy and wanted to make
sure I had the time to sit down and look at this before responding.
Paul Kienzle wrote:
> On Thu, Aug 02, 2007 at 10:31:04AM -0400, Michael Droettboom wrote:
>> I don't know if we ever reached consensus on
Darren Dale wrote:
> On Monday 20 August 2007 10:18:27 am Michael Droettboom wrote:
>> On a related note, there was a recent thread on matplotlib-users about
>> usetex being a global setting:
>>
>> http://www.mail-archive.com/[EMAIL PROTECTED]/msg04101
>>
This was an attempt to do a direct translation from what I had in the
"classic" rcsetup.py. (The previous version in mplconfig.py was
semantically incorrect.) I had tested this with settings in my
matplotlib.conf, but didn't realise that the default wasn't validated
(and thus not interpreted
. Is that
something to be relied on? (Other parts of mplconfig, such as the
colors, depend on this).
Cheers,
Mike
Michael Droettboom wrote:
> This was an attempt to do a direct translation from what I had in the
> "classic" rcsetup.py. (The previous version in mplconfig.py
Darren Dale wrote:
> On Wednesday 22 August 2007 03:09:30 pm Michael Droettboom wrote:
>> I realize it's hacky. The most obvious alternative is to expect a
>> dictionary here, e.g.:
>>
>>rm = { 'family': ['serif'], 'style': 'o
401 - 500 of 1294 matches
Mail list logo
