matplotlib-devel Mailing List for matplotlib (Page 4)

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I just tried running backend_driver.py with numerix set to
 Darren> Numeric, and I'm repeatedly getting the following error:
 Darren> File
 Darren> "/usr/lib64/python2.4/site-packages/matplotlib/axes.py",
 Darren> line 2502, in bar yerr = asarray([yerr]*nbars, Float) #
 Darren> Float converts Nones to NANs File
 Darren> "/usr/lib64/python2.4/site-packages/Numeric/Numeric.py",
 Darren> line 134, in asarray return multiarray.array(a, typecode,
 Darren> copy=0, savespace=savespace) TypeError: a float is
 Darren> required driving image_demo.py
That was in histogram_demo which called bar with xerr=None and
yerr=None and bar was assuming a numpy-ism in converting None to nan.
I just committed a change to fix it.
JDH

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> I fixed that problem in the qt backends by telling the
 Darren> label to ignore sizing hints. We could make the format
 Darren> string shorter, but even then, depending on the size of
 Darren> the window, this problem can occur. What format would you
 Darren> prefer to be reported on the toolbar?
I'm a little confused here because the default should be to use the
axis major formatter (eg in the Axes.format_xdata function). Why
would the default formatter return such a long string?
I don't know what the right answer is: using the default formatter is
usually irritating when plotting dates, since you often want a finer
resolution than you get with the tick formatting (eg if the ticks are
formatted to the nearest day, you may want to see H:M:S when
interacting). Clearly you can override this by using the fmt_xdata
and fmt_ydata attrs, but oftentimes I wish the defaults were better.
As a quick solution, I added a default method to the Formatter base
class
 def format_data_short(self,value):
 'return a short string version'
 return format_data(self,value)
and overrode it for the scalar formatter
 def format_data_short(self,value):
 'return a short formatted string representation of a number'
 return '%1.3g'%value
and used this to format the x and y coords. What do you think about
that (revision 2666)?
JDH

On Thursday 10 August 2006 10:54, John Hunter wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
> Charlie> I periodically am seeing it. But I can't figure out how
>
> I just tested on TkAgg ( I usually use GTKAgg) and noticed another
> problem. When you click "zoom to rect mode" the format string in the
> toolbar becomes so long that it causes the window to resize to fit
> it. As you move the mouse around, depending on the x and y
> locations, the format string becomes longer or shorter and the window
> resizes like mad. Very annoying. Let's hold off on a release until
> we can sort these bugs out.
I just tried running backend_driver.py with numerix set to Numeric, and I'm 
repeatedly getting the following error:
 File "/usr/lib64/python2.4/site-packages/matplotlib/axes.py", line 2502, in 
bar
 yerr = asarray([yerr]*nbars, Float) # Float converts Nones to NANs
 File "/usr/lib64/python2.4/site-packages/Numeric/Numeric.py", line 134, in 
asarray
 return multiarray.array(a, typecode, copy=0, savespace=savespace)
TypeError: a float is required
 driving image_demo.py
Darren

On Thursday 10 August 2006 10:54, John Hunter wrote:
> >>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
> Charlie> I periodically am seeing it. But I can't figure out how
>
> I just tested on TkAgg ( I usually use GTKAgg) and noticed another
> problem. When you click "zoom to rect mode" the format string in the
> toolbar becomes so long that it causes the window to resize to fit
> it. As you move the mouse around, depending on the x and y
> locations, the format string becomes longer or shorter and the window
> resizes like mad. Very annoying. Let's hold off on a release until
> we can sort these bugs out.
I fixed that problem in the qt backends by telling the label to ignore sizing 
hints. We could make the format string shorter, but even then, depending on 
the size of the window, this problem can occur. What format would you prefer 
to be reported on the toolbar?

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> I periodically am seeing it. But I can't figure out how
I just tested on TkAgg ( I usually use GTKAgg) and noticed another
problem. When you click "zoom to rect mode" the format string in the
toolbar becomes so long that it causes the window to resize to fit
it. As you move the mouse around, depending on the x and y
locations, the format string becomes longer or shorter and the window
resizes like mad. Very annoying. Let's hold off on a release until
we can sort these bugs out.
JDH

On 8/10/06, John Hunter <jdh...@ac...> wrote:
>
> I am experiencing some strangeness with the svn version of mpl, but I
> don't know if it is the code or my connection. I am working over X11
> so it may have something to do with that. Could those of you with
> local access to an svn install of mpl test something?
>
> When I open a plot (eg simple_plot.py) and zoom to rect, the plot
> zooms in to the rect, and then strangely zooms back out to the
> original view and then back in again. Anyone else seeing this?
I periodically am seeing it. But I can't figure out how to cause it.

I am experiencing some strangeness with the svn version of mpl, but I
don't know if it is the code or my connection. I am working over X11
so it may have something to do with that. Could those of you with
local access to an svn install of mpl test something?
When I open a plot (eg simple_plot.py) and zoom to rect, the plot
zooms in to the rect, and then strangely zooms back out to the
original view and then back in again. Anyone else seeing this?
JDH

Hi Charlie,
On Monday 07 August 2006 16:49, Charlie Moad wrote:
> My fear is that all these native implementations will become very hard
> to maintain. 
Its only 6 sliders and a reset button. I suggested it because it seemed like 
such a simple task that would be natural to handle with the backends native 
widgets.
> What happens when Qt 4.2 comes out and the person who 
> did the original Qt impl is long gone?
When Qt-4 came out, someone contributed a partially complete backend and I 
finished it because I wanted to use it. 
> Native tools seem better left to developers creating their own apps. The 
> typical user probably won't care if the laf is native, just whether it works
> consistently. 
Is there any objection to my replacing the SubplotTool with native widgets for 
the Qt4 backend? The SubplotTool isn't working there anyway. I'll drop the 
subject as far as the other backends are concerned.
Darren

Hello
=20
I have made a small Qt3 / OpenGL backend which we use for fast animated
plots. It depends on PyOpenGL and a tiny SWIG wrapping of FTGL (texture
mapped FreeType fonts). Using GL directly seemed the quickest way to get
high framerates on large displays. I understand the concerns about a
proliferation of unsupported backends (with no image support, sorry),
but if anyone is interested is there anywhere to upload this where other
people could have a look?
=20
Cheers
James
=20

My fear is that all these native implementations will become very hard
to maintain. What happens when Qt 4.2 comes out and the person who
did the original Qt impl is long gone? (this is just for arguments
sake of course). Native tools seem better left to developers creating
their own apps. The typical user probably won't care if the laf is
native, just whether it works consistently.
On 8/7/06, Mark Bakker <ma...@gm...> wrote:
> Darren -
>
> Although I agree with your on some level, the advantage of the current
> toolbar is that it is easy to incorporate in a GUI, where the user can
> define his own drop down menu. So I vote for a backend native slider, but
> keep the button on the toolbar.
>
> I have been thinking about an easier way to have user-defined toolbars (and
> I am sure others have much better ideas). I would rather put energy towards
> modifyable toolbars than a dropdown menu,
>
> Mark
>
> > ------------------------------
> >
> > Message: 4
> > Date: Mon, 7 Aug 2006 09:34:57 -0400
> > From: Darren Dale <dd...@co...>
> > Subject: [matplotlib-devel] subplots adjust
> > To: mat...@li...
> > Message-ID: <200...@co...>
> > Content-Type: text/plain; charset="us-ascii"
> >
> > I am writing to ask about the subplots adjust widget. I think the gui
> would be
> > better implimented by each backend using the native widgets rather than by
> > the existing set of backend-neutral sliders, which are somewhat
> unbecoming.
> > The proposed backend-specific widgets could call the generic subplot
> resize
> > routines, and really shouldn't be that difficult to impliment. Also, I was
> > thinking that subplot_adjust should be selectable from a standard
> > dropdown "File, Edit, View..." menubar instead of on the main toolbar. The
> > save button could also be moved to the drop down menu bar.
> >
> > Darren
> >
> >
> >
> > ------------------------------
> >
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>

Hey, glad it might actually be of use to other people. I know I've 
been awful about finishing things, as anything that doesn't directly 
relate to my thesis has fallen to wayside as of late. When I was 
investigating saving it as an XML format, I remember coming across a 
problem. If I remember correctly, you could easily write a backend 
that would just spit out the proper XML, but it wouldn't be a very 
good XML file -- it would just be a collection of 'draw_lines', etc.. 
The current format that I've been using looks more like:
<pylab>
<figure name="foo">
<axes pos="1,1">
	<plot name="bar">
		<params name="a" value="10.5" type="float"/>
		<params name="b" value="baz" type="str"/>
	</plot>
</axes>
<axes pos="1,2">
	<plot name="bar">
		<params name="a" value="0.53" type="float"/>
		<params name="b" value="zab" type="str"/>
</axes>
</figure>
</pylab>
It has a plug-in architecture, so it looks for all python files in a 
specified directory, and that is how it decides which plot function 
to call (in this case, it would find a class 'bar' within those 
files). The class specifies what arguments it can take, which are 
required arguments, and which are optional (as well as default values).
What made sense to me, would be to simply create plot classes that 
corresponded with the draw_line, draw_arc, etc. That way, to render a 
saved XML file, would simply consist of having those classes make the 
correct backend calls. But, there doesn't seem an easy way to 
generate this with the backends, as they know nothing about figures, 
axes, subplot, etc.
So it seems like matplotlib would have to have a separate way for 
saving a native format. I think this would be a huge gain, as it 
would allow figures to be generated, saved, edited, reopened/ 
regenerated, but would involve yet another output method.
I could very well be missing something obvious, if so please correct me!
As for the SVG, I'll have to look into it. I think that's probably an 
easier issue, as I believe you could construct it in a similiar 
fashion to the other backends, as a collection of lines.
Abe
On Aug 7, 2006, at 4:14 PM, Andrew Straw wrote:
> Dear Abraham,
>
> I'm sorry it's taken so long to get back to you. I didn't see any 
> other
> responses on the list, but I think this is a super idea (although I 
> have
> yet to look at the code). In particular I like your idea to save to 
> your
> XML format. Then we could plot to an XML file, and replot (later) with
> whatever backend we need at the time. It sounds great. We could 
> even zip
> the file automatically (or just the data parts of the innards) so 
> they'd
> hopefully be pretty small.
>
> I suspect that if you get the XML backend working and incorporate it,
> you'll have a lot of users trying it out when they see it in their 
> "save
> as" format list.
>
> Relatedly, is there any way would could add to the SVG backend that
> would give us essentially this and, simultaneously, a valid SVG 
> file? Is
> SVG even "officially" extensible in this way? (I don't know much about
> SVG or XML.)
>
> Cheers!
> Andrew
>
> Abraham Schneider wrote:
>> Hi. A long while ago I had sent out an email asking if anyone was
>> interested in an XML library for plotting with matplotlib. It seemed
>> the general consensus was no, though it might be nice as a backend 
>> for
>> saving files. So I developed the XML library for my own purposes, and
>> have been using it for some time.
>>
>> I thought I might as well clean it up, package it, and release it in
>> the wild. I'm not sure if this would even qualify as an alpha 
>> release,
>> perhaps more of a RFC, but if anyone is interested, and wants to give
>> some comments, let me know. While it has gotten a good amount of use
>> (including a soon to be published paper), it has evolved to fit my
>> needs more than anything else. So in the clean up, I tried to
>> refractor some saneness into it, and had to fix some things in the
>> process. I tried to test as much of it as possible, but I'm sure I
>> forgot some obvious things as well.
>>
>> It is trying to serve 3 purposes:
>> (1) Framework for making publishable figures easy
>> (2) Provide an easy way to allow pylab figures to be saveable/ 
>> loadable
>> and editable by human
>> (3) Provide a general framework for a higher level plotting library
>>
>> I'm hoping to in the near future write the backend to pylab to 
>> save in
>> the XML format. It should (hopefully) be fairly trivial..
>>
>> It can be found (this includes some documentation and examples):
>> www.cns.nyu.edu/~abes/xmlplot.tar.gz
>>
>> Thanks,
>>
>> Abe
>>
>>
>> -------------------------------------------------------
>> Using Tomcat but need to do more? Need to support web services, 
>> security?
>> Get stuff done quickly with pre-integrated technology to make your 
>> job
>> easier
>> Download IBM WebSphere Application Server v.1.0.1 based on Apache
>> Geronimo
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=120709&bid=263057&dat=121642
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ---------------------------------------------------------------------- 
> ---
> Using Tomcat but need to do more? Need to support web services, 
> security?
> Get stuff done quickly with pre-integrated technology to make your 
> job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache 
> Geronimo
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Dear Abraham,
I'm sorry it's taken so long to get back to you. I didn't see any other
responses on the list, but I think this is a super idea (although I have
yet to look at the code). In particular I like your idea to save to your
XML format. Then we could plot to an XML file, and replot (later) with
whatever backend we need at the time. It sounds great. We could even zip
the file automatically (or just the data parts of the innards) so they'd
hopefully be pretty small.
I suspect that if you get the XML backend working and incorporate it,
you'll have a lot of users trying it out when they see it in their "save
as" format list.
Relatedly, is there any way would could add to the SVG backend that
would give us essentially this and, simultaneously, a valid SVG file? Is
SVG even "officially" extensible in this way? (I don't know much about
SVG or XML.)
Cheers!
Andrew
Abraham Schneider wrote:
> Hi. A long while ago I had sent out an email asking if anyone was
> interested in an XML library for plotting with matplotlib. It seemed
> the general consensus was no, though it might be nice as a backend for
> saving files. So I developed the XML library for my own purposes, and
> have been using it for some time.
>
> I thought I might as well clean it up, package it, and release it in
> the wild. I'm not sure if this would even qualify as an alpha release,
> perhaps more of a RFC, but if anyone is interested, and wants to give
> some comments, let me know. While it has gotten a good amount of use
> (including a soon to be published paper), it has evolved to fit my
> needs more than anything else. So in the clean up, I tried to
> refractor some saneness into it, and had to fix some things in the
> process. I tried to test as much of it as possible, but I'm sure I
> forgot some obvious things as well.
>
> It is trying to serve 3 purposes:
> (1) Framework for making publishable figures easy
> (2) Provide an easy way to allow pylab figures to be saveable/loadable
> and editable by human
> (3) Provide a general framework for a higher level plotting library
>
> I'm hoping to in the near future write the backend to pylab to save in
> the XML format. It should (hopefully) be fairly trivial..
>
> It can be found (this includes some documentation and examples):
> www.cns.nyu.edu/~abes/xmlplot.tar.gz
>
> Thanks,
>
> Abe
>
>
> -------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Darren -
Although I agree with your on some level, the advantage of the current
toolbar is that it is easy to incorporate in a GUI, where the user can
define his own drop down menu. So I vote for a backend native slider, but
keep the button on the toolbar.
I have been thinking about an easier way to have user-defined toolbars (and
I am sure others have much better ideas). I would rather put energy towards
modifyable toolbars than a dropdown menu,
Mark
> ------------------------------
>
> Message: 4
> Date: Mon, 7 Aug 2006 09:34:57 -0400
> From: Darren Dale <dd...@co...>
> Subject: [matplotlib-devel] subplots adjust
> To: mat...@li...
> Message-ID: <200...@co...>
> Content-Type: text/plain; charset="us-ascii"
>
> I am writing to ask about the subplots adjust widget. I think the gui
> would be
> better implimented by each backend using the native widgets rather than by
> the existing set of backend-neutral sliders, which are somewhat
> unbecoming.
> The proposed backend-specific widgets could call the generic subplot
> resize
> routines, and really shouldn't be that difficult to impliment. Also, I was
> thinking that subplot_adjust should be selectable from a standard
> dropdown "File, Edit, View..." menubar instead of on the main toolbar. The
> save button could also be moved to the drop down menu bar.
>
> Darren
>
>
>
> ------------------------------
>

>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
 Charlie> Are they any lingering issues that would prevent a
 Charlie> Wednesday minor rev bump for the latest numpy? Ideally
 Charlie> it would last through the numpy 1.0 release.
Since scipy is next week, we should concentrate on getting a release
out that works with whatever numpy/scipy Travis is targeting for the
scipy conference.
JDH

On 8/7/06, Christopher Barker <Chr...@no...> wrote:
> Darren Dale wrote:
> > On Monday 07 August 2006 08:55, Charlie Moad wrote:
> > Pushing a
> >> release now for 1.0 might be pointless, since the C-api could possibly
> >> change and break compatibility again. After all, it still is a beta.
>
> > I wonder how long we should continue to hold off on a new release. As I said
> > in a previous email, Travis does not foresee changes to the C API before
> > numpy-1.1 (although he doesn't rule them out). Besides, several bug fixes and
> > new features have been added since 0.87.4.
>
> Isn't the "current" version using numpy 0.9.8? No matter, they are ALL
> beta, (or alpha), so there is no reason to stick with any particular one.
>
> 1.0b seems to be the least buggy and most future-proof (which, of
> course, doesn't mean that much) at the moment, so I say we do it.
>
> Charlie, can you do OS-X? I still don't have my build environment set up
> quite right, and you beat me to it last time. We'll need to put a new
> numpy mpkg on pythonmac.org at the same time. I'd be glad to do that, if
> it helps, but I need to make sure we use the same version.
Are they any lingering issues that would prevent a Wednesday minor rev
bump for the latest numpy? Ideally it would last through the numpy
1.0 release.
- Charlie

Eric Firing wrote:
> I think the following (now in svn) should be OK; it seems to work on 
> Windows, at least in the sense that it doesn't trigger an exception.
> 
> nan = struct.unpack('d', struct.pack('Q', 0x7ff8000000000000))[0]
It works on OS-X PPC also. I was wondering about endian issues.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

I am writing to ask about the subplots adjust widget. I think the gui would be 
better implimented by each backend using the native widgets rather than by 
the existing set of backend-neutral sliders, which are somewhat unbecoming. 
The proposed backend-specific widgets could call the generic subplot resize 
routines, and really shouldn't be that difficult to impliment. Also, I was 
thinking that subplot_adjust should be selectable from a standard 
dropdown "File, Edit, View..." menubar instead of on the main toolbar. The 
save button could also be moved to the drop down menu bar.
Darren

Robert Kern wrote:
> Eric Firing wrote:
> 
>> I added nan definitions for
>>Numeric and numarray which work on my linux box, but I have not tested 
>>them on other platforms; I guess in the worst case, if it doesn't work 
>>on Mac or Windows I will have to change quiver.py to use masked arrays 
>>internally instead of nans. (The definition I used is "nan = 
>>float('nan')".)
> 
> 
> That will certainly not work on Windows.
> 
Thanks for the quick info.
I think the following (now in svn) should be OK; it seems to work on 
Windows, at least in the sense that it doesn't trigger an exception.
nan = struct.unpack('d', struct.pack('Q', 0x7ff8000000000000))[0]
Eric

Eric Firing wrote:
> I added nan definitions for
> Numeric and numarray which work on my linux box, but I have not tested 
> them on other platforms; I guess in the worst case, if it doesn't work 
> on Mac or Windows I will have to change quiver.py to use masked arrays 
> internally instead of nans. (The definition I used is "nan = 
> float('nan')".)
That will certainly not work on Windows.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Travis E. Oliphant wrote:
> I think a numpy-ism crept into the code-base (not that I particularly 
> mind as I will welcome the day matplotlib jettisons it's 3-array support).
So will I! I don't have John's saintly patience, although I understand 
his rationale. My error in this case was failing to test a change I 
made with all three packages, although I try to do that whenever I think 
there might be a problem.
> 
> In quiver.py, nx.nan is attempted, which raises an error, unless I'm 
> missing the definition of nan somewhere.
Well, it was working at least with the version of numpy I had when I 
made the change in quiver to use nan internally as a mechanism for 
supporting masked array input. I have updated to svn, and it works with 
your change of course, so all is well. I added nan definitions for 
Numeric and numarray which work on my linux box, but I have not tested 
them on other platforms; I guess in the worst case, if it doesn't work 
on Mac or Windows I will have to change quiver.py to use masked arrays 
internally instead of nans. (The definition I used is "nan = 
float('nan')".) I used nan here because it considerably simplifies the 
code, now that nan is supported in the primary backends.
Eric

I think a numpy-ism crept into the code-base (not that I particularly 
mind as I will welcome the day matplotlib jettisons it's 3-array support).
In quiver.py, nx.nan is attempted, which raises an error, unless I'm 
missing the definition of nan somewhere.
In SVN, I have imported nan from numpy explicitly
Best,
-Travis

Christopher Barker wrote:
> Darren Dale wrote:
> 
>> Travis says that barring the discovery of some issue during the beta period, 
>> the C API will not change before numpy-1.1. I think an exe may be necessary 
>> as well.
>> 
>
> and an OS-X mpkg, if you're set up to do that -- also, we'd need to 
> build an mpkg of the numpy you used as well.
>
> I don't know if it's time to do that quite yet though.
>
> 
Wait a bit until I get the Numeric backward-compatibility module 
straightened out. Some name imports in matplotlib may have to change 
again to get it right.
This should be done by the end of the weekend.
-Travis

On 8/4/06, David Flory <li...@th...> wrote:
> At 8/2/2006 3:57 PM Charlie Moad wrote:
> > I have this on hand right now.
> >
> > http://euclid.uits.iupui.edu/~cmoad/matplotlib-0.87.4_r2645-py2.4-win32.egg
> >
> > I could make an exe build if you woudl prefer that. How long is numpy
> > supposed to be in beta?
> >
> > - Charlie
> >
> > On 8/2/06, Darren Dale <dd...@co...> wrote:
> >> Any chance we can get a binary release together to work with the latest
> >> version of numpy? There are some posts on scipy-user complaining that 0.87.4
> >> wont work with numpy C API version 1000000 (numpy-1.0b1).
> >>
> >> Darren
> >>
>
> Charlie,
>
> I downloaded your egg and tried to Easy_Install it. I got errors.
> (Warning: total novice at eggs) Below are the errors. Any suggestions?
I had bed perms on the file. It's fixed now. I'm curious how you
downloaded it in the first place? Ah well.

At 8/2/2006 3:57 PM Charlie Moad wrote:
> I have this on hand right now.
> 
> http://euclid.uits.iupui.edu/~cmoad/matplotlib-0.87.4_r2645-py2.4-win32.egg
> 
> I could make an exe build if you woudl prefer that. How long is numpy
> supposed to be in beta?
> 
> - Charlie
> 
> On 8/2/06, Darren Dale <dd...@co...> wrote:
>> Any chance we can get a binary release together to work with the latest
>> version of numpy? There are some posts on scipy-user complaining that 0.87.4
>> wont work with numpy C API version 1000000 (numpy-1.0b1).
>>
>> Darren
>>
Charlie,
I downloaded your egg and tried to Easy_Install it. I got errors.
(Warning: total novice at eggs) Below are the errors. Any suggestions?
Cheers, David
D:\Software Archive\Python\MatPlotLib>easy_install
matplotlib-0.87.4_r2645-py2.4
-win32.egg
Processing matplotlib-0.87.4_r2645-py2.4-win32.egg
Traceback (most recent call last):
 File "C:\Python24\Scripts\easy_install-script.py", line 7, in ?
 sys.exit(
 File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 1588, in main
 with_ei_usage(lambda:
 File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 1577, in with_ei_usage
 return f()
 File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 1591, in <lambda>
 distclass=DistributionWithoutHelpCommands, **kw
 File "C:\Python24\Lib\distutils\core.py", line 149, in setup
 dist.run_commands()
 File "C:\Python24\Lib\distutils\dist.py", line 946, in run_commands
 self.run_command(cmd)
 File "C:\Python24\Lib\distutils\dist.py", line 966, in run_command
 cmd_obj.run()
 File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 211, in run
 self.easy_install(spec, not self.no_deps)
 File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 427, in easy_install
 return self.install_item(None, spec, tmpdir, deps, True)
 File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 471, in install_item
 dists = self.install_eggs(spec, download, tmpdir)
 File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 619, in install_eggs
 return [self.install_egg(dist_filename, tmpdir)]
 File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 670, in install_egg
 dist = self.egg_distribution(egg_path)
 File
"c:\python24\lib\site-packages\setuptools-0.6c1-py2.4.egg\setuptools\comm
and\easy_install.py", line 661, in egg_distribution
 metadata = EggMetadata(zipimport.zipimporter(egg_path))
zipimport.ZipImportError: not a Zip file:
'matplotlib-0.87.4_r2645-py2.4-win32.e
gg'
D:\Software Archive\Python\MatPlotLib>

On 8/2/06, John Hunter <jdh...@ac...> wrote:
> OK, but I reiterate my point from my last post on the subject. The
> work you have done previously as far as I understand is still not
> usable. You need to develop a system wherein mathtext can be used
> with a set of unicode fonts, so that when the STYX fonts are released
> we can use them. Even if the example font set does not have full
> coverage, we need to develop a prototype so that users and developers
> can test your work. Something like
>
> - here are a set of test fonts: http://some.web.site
>
> - here are the changes you need to make to your rc file
>
> - here is a test script
>
Thanks!
I apologise for keeping the development in obscurity. The procedure
(the best I could come up with):
1) Here are a set of test fonts:
http://download.savannah.gnu.org/releases/freefont/freefont-ttf-20060126.tar.gz
Make sure you extract the files FreeSerif.ttf, FreeMono.ttf to the mpl-data dir.
2) Changes needed to the files: You have to change __init__.py and
mathtext.py (the files are attached) and you also have to add some
lines to matplotlibrc (also attached).
The __init__.py/matplotlibrc changes are trivial:
 # mathtext settings
 'mathtext.unicode' : [False, validate_bool], # Needed to enable Unicode
 # fonts used by mathtext
 'mathtext.rm' : ['FreeSerif.ttf', str], # Roman (normal)
 'mathtext.it' : ['FreeSerif.ttf', str], # Italic
 'mathtext.tt' : ['FreeMono.ttf', str], # Typewriter (monospaced)
 'mathtext.cal' : ['cmsy10.ttf', str], # Caligraphic
Although the default setting for 'mathtext.unicode' is False, the
attached matplotlibrc sets it to True.
The mathtext.py changes are also trivial.
3) mathtext_demo.py will do as a test script. I have added some TeX
symbols to the mathtext_demo.py that is attached with this e-mail.
Note that the attached mathtext_demo.py saves a png, svg and ps file
in the working dir.
Again, I didn't want to commit to the svn, because, as a newbie, I'm
not completely sure if the proposed changes will break something, or
if I should have done things differently.
Any feedback is welcome, only note that the current parsing doesn't
allow some things that in plain TeX you take for granted (I'm
developing a new parser already). The changes only show the current
state of Unicode support in the Font classes.
Cheers
Edin