matplotlib-devel Mailing List for matplotlib (Page 5)

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.
-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...

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.
On Wednesday 02 August 2006 15:57, 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
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your opinions on IT & business topics through brief surveys -- and earn
> > cash
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Darren S. Dale, Ph.D.
Cornell High Energy Synchrotron Source
Cornell University
200L Wilson Lab
Rt. 366 & Pine Tree Road
Ithaca, NY 14853
dd...@co...
office: (607) 255-9894
fax: (607) 255-9001

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
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

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

Darren Dale wrote:
> I'm actually very hopeful. It's because the TeX code is so well written and 
> documented that the algorithms can (hopefully) be easily ported to Python. 
Good point. I've never looked deep enough to know how complicated the 
algorithms really are -- and we're not trying to build something that 
will run LaTeX here. Although, It would be very useful to be able to use 
add-on packages -- amsmath, if nothing else.
> The problem I have with TeX is 
> that it has a lot of overhead (it's not meant to be used as a daemon), is not 
> intended to be used as a library (as far as I have been able to discern),
These are key -- and what I've been fantasizing for years is that 
someone will re-write to be used as a library.
> and 
> still requires interpretation once the results are produced
DVI is actually pretty simple -- I don't think that's the hard part of 
the problem.
> The usetex option, which produces excellent
> results, has been an absolute headache to maintain across platforms.
I'm sure! dependency on an external TeX distribution is not a good 
long-term option.
 > Which other projects did you have in mind?
I've seen a couple that are trying to make a version of TeX that can be 
used as a lib -- with just this kind of thing in mind. How active they 
are, and whether they will get anywhere remains to be seen.
Here's one that doesn't look active:
http://www.metatex.org/
and another: but JAVA? argg!
http://www.extex.org/index.html
That might still be a good site to check out if one is to re-write the 
TeX layout engine in Python...
Even if there aren't any other projects to leverage, while less fun, I 
expect that making a library version of TeX from the existing code base 
would result in a far more robust result.
Another option is to build a stripped down TeX distribution that we 
would deliver with MPL. Also a lot of work, but it could be restricted 
to only a small number of fonts, packages, etc.
Anyway, anything that someone will do (and get paid for!) is fine with me!
-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...

On Wednesday 02 August 2006 11:59, Christopher Barker wrote:
> John Hunter wrote:
> > the STYX fonts are released
>
> did you mean the STIX fonts?
>
> http://www.stixfonts.org/
>
> > - here are a set of test fonts: http://some.web.site
>
> Is that really the link?
"Please repeat after me: I, say your name..."
"I, say your name..."

John Hunter wrote:
> the STYX fonts are released
did you mean the STIX fonts?
http://www.stixfonts.org/
> - here are a set of test fonts: http://some.web.site
Is that really the link?
-- 
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...

>>>>> "Edin" =3D=3D Edin Salkovi=A7 <edi...@gm...> writes:
 Edin> I'm still alive ;) Although I still haven't received any
 Edin> payments from Google (they are doing their best to solve
 Edin> this), I've began working on implementing the Knuth's layout
 Edin> algorithms.
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
I think it is unproductive to move on to new projects before the first
one is completed and usable. Or if am missing something and the work
is usable, please provide a brief set of instructions as above so we
can test it.
JDH

I'm still alive ;)
Although I still haven't received any payments from Google (they are
doing their best to solve this), I've began working on implementing
the Knuth's layout algorithms.
I have studied a bit the TeXbook, the existing mathtext parsing code,
and I have decided to rewrite the parsing almost from scratch.
Although I don't no too much about parsing, I think it won't be that
much of a problem.
My idea is to first transform a TeX string to a Python list (tree-like
structure), which can be composed of strings, commands, and/or other
lists, and so on.
Then, I plan to write some classes to trasnform this list/tree to the
actual boxes needed for displaying.
The first part is done (although bugs are possible). Now I'm
concetrating on the remaining part.
The current module is attached. It doesn't need any third-party
libraries currently.
The following works:
Going from:
r"asdf { \horse{}\ \zztop{} \ Hello\^^a^{b_c}}"
to:
['asdf', ' ', [' ', '\\horse', [], '\\space', '\\zztop', [], ' ',
'\\space', 'Hello', '\\circumflex', '\\superscript', 'a',
'\\superscript', ['b', '\\subscript', 'c']]]
Please John, do comment (others with spare time are welcome too :).

> There are two kinds of images in matplotlib -- AxesImage and
> FigureImage. By definition, the AxesImage is interpolated to fit into
> the Axes box. You can control the aspect ratio of the interpolation,
> but it will be interpolated. FigureImage, on the other hand, performs
> a pixel dump to the postscript canvas at the location you tell it to
> -- see examples/figimage_demo.py. It should like you are more
> interested in the latter.
I've had a play with FigureImage and I can't see how to make it draw
the image inside the axes, it seems to only draw it in the background.
> If the figure image doesn't work for you, describe your use-case in
> some detail and why neither work and we'll see if we can accommodate
> it.
OK, so imshow does exactly what I want. The only problem is the
resampling. Each pixel represents a value calculated at a point on a
318x301 grid, so in resampling I loose or distort some of the fine
detail. I do not understand why the image need to be resampled when
using a vector based backend. I understand this is necessary for a
raster backend, but surely with a vector backend you can just scale
the image keeping the 318x301 resolution. I know this is possible in
Postscript at least as I've produced the desired output by
amalgamating two files. See
http://jimmacdonald.co.uk/matplotlib/image_CORRECT_ps_hacked.eps
I looked at using pcolor instead, but the postscript files where too
big (~20MB) due to the large number of tiles (this is how I used to do
it in matlab).
JIM
----