matplotlib-users Mailing List for matplotlib

Thanks to you all, this is another example how open source software works.=
=20
We tend to take it for granted now, but actually... it is amazing!

thanks,
Dimitri

On 6/3/05, John Hunter <jdh...@ac...> wrote:
>=20
> >>>>> "Steve" =3D=3D Steve Chaplin <ste...@ya...> writes:
>=20
> Steve> I updated backend_gtk.py in cvs to remove the DBL_BUFFER
> Steve> code - it was just an experimental feature and I do not
> Steve> think anyone had a use for it, and it was confusing the
> Steve> rest of the code. I added the call to
> Steve> self.window.clear_area() which should solve the
> Steve> problem. Could someone using PyGTK 2.6 install from cvs and
> Steve> let me know if it works.
>=20
>=20
> These changes fixed the problem for 2.6.
>=20
> Thanks Steve!
>=20
> JDH
>=20
>=20
> -------------------------------------------------------
> This SF.Net <http://SF.Net> email is sponsored by Yahoo.
> Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
> Search APIs Find out how you can build Yahoo! directly into your own
> Applications - visit http://developer.yahoo.net/?fr=3Doffad-ysdn-ostg-q22=
005
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>=20



--=20
Please visit dimitri's website: www.serpia.com <http://www.serpia.com>

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> I updated backend_gtk.py in cvs to remove the DBL_BUFFER
    Steve> code - it was just an experimental feature and I do not
    Steve> think anyone had a use for it, and it was confusing the
    Steve> rest of the code.  I added the call to
    Steve> self.window.clear_area() which should solve the
    Steve> problem. Could someone using PyGTK 2.6 install from cvs and
    Steve> let me know if it works.


These changes fixed the problem for 2.6.

Thanks Steve!

JDH

Nicolas,

 >>up to now I've been using contourf() with the gray colormap so I hardly
 >>noticed this problem until now: the highest values of the contour do 
not get
 >>the right color.


I think the problem you describe is fixed by a patch I submitted a few 
hours ago; it corrects an error I introduced when revising the mpl 
interface to the underlying contouring routines.

Eric

>>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes:

    Nicolas> On Friday 03 June 2005 00:31, John Hunter wrote:
    >> A freestanding script which exposes the bug, as well as the
    >> output when you run it on your system with --verbose-helpful,
    >> would be most helpful to us in tracking down this bug.
    >> 
    Nicolas> OK, here you are : I just ran the contour_demo.py from
    Nicolas> the examples directory as follows:

    Nicolas>   $ python contour_demo.py --verbose-helpful >&
    Nicolas> contour.log

    Nicolas> You'll find the contour.log file attached to this mail.

    Nicolas> I'm afraid I'll have to leave you, as it's quite late
    Nicolas> here in France...
 
I do not get this error running the matplotlib
examples/contour_demo.py with matplotlib CVS

peds-pc311:~/python/projects/matplotlib/examples> python contour_demo.py --verbose-helpful
matplotlib data path /usr/share/matplotlib
loaded rc file /home/jdhunter/.matplotlibrc
matplotlib version 0.81alpha
verbose.level helpful
interactive is False
platform is linux2
numerix Numeric 24.0b2
font search path ['/usr/share/matplotlib']
loaded ttfcache file /home/jdhunter/.ttffont.cache
backend GTKAgg version 2.4.1
Traceback (most recent call last):

My best guess is that your Numeric version 23.1, is too old.  Could
you upgrade Numeric and try again?

Thanks!
JDH

William Henney wrote:

> Yes, I wasn't thinking of specialized data formats. Python already has
> fine support for reading, e.g., FITS files. I was thinking more along
> the lines of gnuplot's support for simple ascii data tables. E.g., easy
> selection of columns to plot, single blank line indicating a gap in the
> plot, double blank line indicating a new dataset, etc. This is all
> trivial stuff that I can easily write myself but it would be nice if it
> were a part of the plotting package (PyX does this well). It's not
> really a sticking point though. 

scipy's read_array, while not identical to gnuplot's, isn't bad at all:

In [8]: scipy.io.read_array?
Type:           function
Base Class:     <type 'function'>
String Form:    <function read_array at 0x4083c614>
Namespace:      Interactive
File:           /usr/lib/python2.3/site-packages/scipy/io/array_import.py
Definition:     scipy.io.read_array(fileobject, separator=None, 
columns=None, comment='#', lines=None, atype='d', linesep='\n', 
rowsize=10000, missing=0)
Docstring:
     Return an array or arrays from ascii_formatted data in |fileobject|.

     Inputs:

       fileobject -- An open file object or a string for a valid filename.
                     The string can be prepended by "~/" or "~<name>/" to
                     read a file from the home directory.
       separator -- a string or a tuple of strings to indicate the column
                    separators.  If the length of the string tuple is less
                    than the total number of columns, then the last 
separator
                    is assumed to be the separator for the rest of the 
columns.
       columns -- a tuple of integers and range-tuples which describe the
                  columns to read from the file.  A negative entry in the
                  last column specifies the negative skip value to the end.
                  Example:  columns=(1, 4, (5, 9), (11, 15, 3), 17, -2)
                          will read [1,4,5,6,7,8,11,14,17,19,21,23,...]
                  If multiple arrays are to be returned, then this argument
                  should be an ordered list of such tuples.  There should be
                  one entry in the list for each arraytype in the atype 
list.
       lines   -- a tuple with the same structure as columns which indicates
                  the lines to read.
       comment -- the comment character (line will be ignored even if it is
                  specified by the lines tuple)
       linesep -- separator between rows.
       missing -- value to insert in array when conversion to number fails.
       atype -- the typecode of the output array.  If multiple outputs are
                desired, then this should be a list of typecodes.  The 
columns
                to fill the array represented by the given typecode is
                determined from the columns argument.  If the length of 
atype
                does not match the length of the columns list, then, the
                smallest one is expanded to match the largest by repeatedly
                copying the last entry.
       rowsize -- the allocation row size (array grows by this amount as
                data is read in).

     Output -- the 1 or 2d array, or a tuple of output arrays of different
               types, sorted in order of the first column to be placed
               in the output array.

cheers,

f

>>>>> "Yves" == Yves Moisan <ym...@gr...> writes:

    Yves> Hi, I am struggling to implement the equivalent of
    Yves> http://plone.org/documentation/how-to/add-charts to add
    Yves> charting capacilities to a Plone content type.  The example
    Yves> uses PyChart, but I tried replacing the PyChart code with
    Yves> matplotlib code.  Here it is :

agg is already configured to write to a file object rather than a
filename.  Is there anything that you can use that can be converted to
a file pointer?  Eg, you can pass sys.stdout to savefig, unless
sys.stdout has been hijacked, which mod_python appears to do

Also, I do not recommend using the pylab interface in a web app
server.  See

  http://matplotlib.sourceforge.net/faq.html#OO

If anyone else has any ideas on how to get a StringIO-like object,
which exposes the file pointer interface needed by libpng, let me
know.  This is what we are currently doing in extension code

  if (o.isString()) {
    std::string fileName = Py::String(o);
    const char *file_name = fileName.c_str();
    if ((fp = fopen(file_name, "wb")) == NULL) 
      throw Py::RuntimeError( Printf("Could not open file %s", file_name).str() );
  }
  else {
    if ((fp = PyFile_AsFile(o.ptr())) == NULL) 
      throw Py::TypeError("Could not convert object to file pointer");
    fpclose = false;
  }
  

JDH

Hi Chris

On Thu, 2005-06-02 at 12:28 -0400, Darren Dale wrote:
> > One thing you need to bear in mind if you are using TeX to
> > generate PS output is that the resultant files will probably be
> > unacceptable to many scientific journals without further processing. The
> > production staff generally try to open the PS files in Adobe Illustrator
> > and this causes multiple problems with files generated both by PyX and
> > by dvips. 
> 
> Why is this?
> 

The main problem was the fonts. The first thing they do as a matter of
policy is to open the file in Adobe Illustrator. This requires that the
full font be present in the file apparently (I only have this second
hand) because Illustrator allows you to edit the text of the labels. A
little bit like running a PS file through pstoedit and then editing it
with xfig I guess - that doesn't work with TeX fonts either.

Here is the thread from when I raised the issue with the helpful folk on
comp.text.tex

http://groups-beta.google.com/group/comp.text.tex/browse_frm/thread/d19575460c561d6b/d447807bb7813dba

There may be a solution that does not involve converting all fonts to
paths but that was the easiest way out since I was under time-pressure
and dealing with production staff who seemed to be working from a very
limited script :) 

> > The solution is to convert all fonts to outlines before 
> > submission (and also make sure all bbox coords are +ve). You can do this
> > with recent versions of ghostscript:
> >
> >  gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=epswrite -dEPSFitPage \
> >     -sOutputFile=new.eps old.eps
> 
> Coincidentally, I was just addressing the use of gs's epswrite this morning on 
> the matplotlib-devel list. Unfortunately, epswrite will yield a file that 
> does not render well on screen. Given the increasing popularity of online 
> publication, it seems this approach for generating eps files would not be 
> acceptable to scientific journals either.
> 

I think it looks fine so long as you turn on the "Smooth line art"
option in your PDF viewer. Unfortunately, this is not on by default in
acroread, presumably because it increases rendering times. 

If someone can come up with a foolproof way to make figures containing
TeX fonts that are acceptable to scientific journals, I, for one, would
be very grateful.
 

> > 1. Good, flexible support for reading data from files
> 
> Could you give an example? In my experience, datafiles tend to get so 
> complicated that all of Matlabs tools were useless. I end up writing code 
> specific to every type that isnt as simple as a few comment lines that are 
> ignored followed by a delimited array of data
> 

Yes, I wasn't thinking of specialized data formats. Python already has
fine support for reading, e.g., FITS files. I was thinking more along
the lines of gnuplot's support for simple ascii data tables. E.g., easy
selection of columns to plot, single blank line indicating a gap in the
plot, double blank line indicating a new dataset, etc. This is all
trivial stuff that I can easily write myself but it would be nice if it
were a part of the plotting package (PyX does this well). It's not
really a sticking point though. 

Cheers

Will 

On Friday 03 June 2005 00:31, John Hunter wrote:
> A freestanding script which exposes the bug, as well as the output
> when you run it on your system with --verbose-helpful, would be most
> helpful to us in tracking down this bug.
>
OK, here you are : I just ran the contour_demo.py from the examples directory 
as follows:

  $ python contour_demo.py --verbose-helpful >& contour.log

You'll find the contour.log file attached to this mail.

I'm afraid I'll have to leave you, as it's quite late here in France...

Bonne nuit !

Cheers,
Nicolas

>>>>> "Nicolas" == Nicolas Girard <nic...@ne...> writes:

    Nicolas> On Friday 03 June 2005 00:21, Nicolas Girard wrote:
    >> Err... the remaining problem that came with my cvs update is a
    >> ZeroDivisionError when an axis is drawn (I guess so):
    >> 

    Nicolas> To be more precise, the problem only shows up when using
    Nicolas> the colorbar function, with either vertical or horizontal
    Nicolas> orientation...

A freestanding script which exposes the bug, as well as the output
when you run it on your system with --verbose-helpful, would be most
helpful to us in tracking down this bug.

Thanks,
JDH

On Friday 03 June 2005 00:21, Nicolas Girard wrote:
> Err... the remaining problem that came with my cvs update is a
> ZeroDivisionError when an axis is drawn (I guess so):
>

To be more precise, the problem only shows up when using the colorbar 
function, with either vertical or horizontal orientation...

On Friday 03 June 2005 00:01, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
>     Eric> Here is the message I sent including the patch; I would not
>     Eric> expect it to have been committed yet, and even if it had
>     Eric> been, John always warns that there can be substantial delays
>     Eric> in updating cvs mirrors.  Note that the patch is against the
>     Eric> version of cntr.c available via cvs this morning.
>
> I just committed it.  Sourceforge is promising to fix this lag but we
> shall see.
>
Err... the remaining problem that came with my cvs update is a 
ZeroDivisionError when an axis is drawn (I guess so):

-----
/usr/lib/python2.4/site-packages/Numeric/MLab.py 
in mean(m=array('...', []), axis=0)
    152     return minimum.reduce(m,axis)
    153
    154 # Actually from Basis, but it fits in so naturally here...
    155
    156 def ptp(m,axis=0):
    157     """ptp(m,axis=0) returns the maximum - minimum along the the 
               given dimension
    158     """
    159     m = asarray(m)
    160     return max(m,axis)-min(m,axis)
    161
    162 def mean(m,axis=0):
    163     """mean(m,axis=0) returns the mean of m along the given dimension.
    164        If m is of integer type, returns a floating point answer.
    165     """
    166     m = asarray(m)
--> 167     return add.reduce(m,axis)/float(m.shape[axis])
        global add.reduce = <built-in method reduce of ufunc object at 
0xb6e124a0>
        m = zeros((0,), 'l')
        axis = 0
        global float = undefined
        m.shape = (0,)

ZeroDivisionError: float division
-----

Any idea ?

On Friday 03 June 2005 00:01, John Hunter wrote:
> >>>>> "Eric" == Eric Firing <ef...@ha...> writes:
>
>     Eric> Here is the message I sent including the patch; I would not
>     Eric> expect it to have been committed yet, and even if it had
>     Eric> been, John always warns that there can be substantial delays
>     Eric> in updating cvs mirrors.  Note that the patch is against the
>     Eric> version of cntr.c available via cvs this morning.
>
> I just committed it.  Sourceforge is promising to fix this lag but we
> shall see.
>

OK, I've just tried it and the "wrong color for highest values" problem seems 
to be gone here : many thanks to both of you !

Nicolas

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:


    Eric> Here is the message I sent including the patch; I would not
    Eric> expect it to have been committed yet, and even if it had
    Eric> been, John always warns that there can be substantial delays
    Eric> in updating cvs mirrors.  Note that the patch is against the
    Eric> version of cntr.c available via cvs this morning.

I just committed it.  Sourceforge is promising to fix this lag but we
shall see.

Checking in src/cntr.c;
/cvsroot/matplotlib/matplotlib/src/cntr.c,v  <--  cntr.c
new revision: 1.3;

Thanks,
JDH

Nicolas,


 > oh, wait : has your patch already been  committed into cvs, or just
 > submitted ? In the latter case, would you please send it to me so 
that I try
 > it ?
 >
 > Nicolas


Here is the message I sent including the patch; I would not expect it to 
have been committed yet, and even if it had been, John always warns that 
there can be substantial delays in updating cvs mirrors.  Note that the 
patch is against the version of cntr.c available via cvs this morning.

Eric

On Thursday 02 June 2005 22:29, Nicolas Girard wrote:
> On Thursday 02 June 2005 22:09, you wrote:
> > Nicolas,
> >
> >  >>up to now I've been using contourf() with the gray colormap so I
> >  >> hardly noticed this problem until now: the highest values of the
> >  >> contour do
> >
> > not get
> >
> >  >>the right color.
> >
> > I think the problem you describe is fixed by a patch I submitted a few
> > hours ago; it corrects an error I introduced when revising the mpl
> > interface to the underlying contouring routines.
> >
> > Eric
>
> Unfortunately it's worse than before: after updating my sandbox &
> recompiling, the same cote than previously lead to a ZeroDivisionError !
>
> The ipython crash file is attached to this mail ; I deeply hope you can use
> it...
>

oh, wait : has your patch already been  committed into cvs, or just 
submitted ? In the latter case, would you please send it to me so that I try 
it ?

Nicolas

On Thursday 02 June 2005 22:09, you wrote:
> Nicolas,
>
>  >>up to now I've been using contourf() with the gray colormap so I hardly
>  >>noticed this problem until now: the highest values of the contour do
>
> not get
>
>  >>the right color.
>
> I think the problem you describe is fixed by a patch I submitted a few
> hours ago; it corrects an error I introduced when revising the mpl
> interface to the underlying contouring routines.
>
> Eric

Unfortunately it's worse than before: after updating my sandbox & recompiling, 
the same cote than previously lead to a ZeroDivisionError !

The ipython crash file is attached to this mail ; I deeply hope you can use 
it...

Nicolas

Hi,

I am struggling to implement the equivalent of
http://plone.org/documentation/how-to/add-charts to add charting capacilities to
a Plone content type.  The example uses PyChart, but I tried replacing the
PyChart code with matplotlib code.  Here it is :

...
from cStringIO import StringIO
import matplotlib
matplotlib.use('Agg')
from pylab import *

...

  def MakePlot (self,):

    #imageFile = StringIO()   
	
    t = arange(0.0, 2.0, 0.01)
    s = sin(2*pi*t)
    plot(t, s, linewidth=1.0)

    xlabel('time (s)')
    ylabel('voltage (mV)')
    title('Graphique dans Archetypes')
    grid(True)
    savefig("C:\\temp\\test.png")
    fh = open("C:\\temp\\test.png", "rb")
    data = fh.read()
    self.setMyImage(data,mimetype='image/png')
    fh.close()
    clf()
    close("all")

This code works perfectly, but I would like to avoid writing a temp file on the
filesystem, that is savefig(imageFile).  Is there a way to use a StringIO object
with savefig ?  

Thanx

Yves Moisan

William Henney wrote:
> Hi list
> 
> On Wed, 2005-06-01 at 13:25 -0500, John Hunter wrote:
> 
>>>>>>>"Chris" == Chris Barker <Chr...@no...> writes:
>>
>>    Chris> Wonderful! this is great news. How have you done it? Have
>>    Chris> you written a DVI driver? or do you use TeX and associated
>>    Chris> tools to create a bitmap and put that on the image? Or
>>    Chris> something else?
>>
>>For *Agg, we use tex + dvipng and load the output as a transparent,
>>anti-aliased raster, caching the dvipng output in ~/.tex.cache for
>>efficiency.  For PS, we use tex + dvips + psfrag + latex + a patched
>>ps2epsi.  The latter is cumbersome, but it works.  In an ideal world,
>>we would simply use tex + dvips but embedding the postscript fragments
>>generated by dvips in arbitrary locations on the figure, but this has
>>proved challenging.
>>
> 
> 
> Have you looked at how PyX (http://pyx.sourceforge.net/) handles things?
> They have excellent support for tex/latex labels and it seems to be
> implemented in a much "cleaner" way than you describe above. As far as I
> can see, they run a single TeX job containing all the strings from the
> current plot (see the texrunner class in pyx/text.py) and then parse the
> dvi output themselves (see pyx/dvifile.py)
> 
> 
>>Having our own dvi parser would be a nice solution.  As you noted, the
>>format isn't too complicated, except for the font handling and the
>>fact that you need your own bytecode processing engine to extract the
>>information.  We're waiting until Robert Kern has another boring
>>experiment to site through for this one.
> 
> 
> Well, PyX is GPLed so I don't see why you couldn't adopt their DVI
> parser.

Because matplotlib isn't GPL'd. It would probably be worth asking the 
PyX developers if they'd be willing to share the code under another 
license (essentially the python license), however.

> The features it seemed to be lacking the last time I looked in any
> detail (v 0.70) were
> 
> 1. Good, flexible support for reading data from files

This really isn't a plotting issue, it's an IO issue. there's some good 
stuff in SciPy for this. I've also written a fast file scanner, kind of 
like Matlab's fscanf. Someone asked if they could put it in SciPy, but 
I'm not sure if it ever made there. Let me know if you want it.

Also, Python itself provides everything you need to read files.

> 2. Publication-quality text handling for math and accented characters
> (i.e., full LaTeX support)

Yeah, this is cool. I only wish that there was a designed-to-be-embedded 
TeX distribution out there. There are all kinds of applications for it, 
and requiring a full TeX distro is a pretty big burden for folks that 
don't use it already. Of course, if they do, then this is an easy way to 
get great typesetting.

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

Hi William,

On Thursday 02 June 2005 11:49 am, William Henney wrote:
> Hi list
>
> On Wed, 2005-06-01 at 13:25 -0500, John Hunter wrote:
> > >>>>> "Chris" =3D=3D Chris Barker <Chr...@no...> writes:
> >
> >     Chris> Wonderful! this is great news. How have you done it? Have
> >     Chris> you written a DVI driver? or do you use TeX and associated
> >     Chris> tools to create a bitmap and put that on the image? Or
> >     Chris> something else?
> >
> > For *Agg, we use tex + dvipng and load the output as a transparent,
> > anti-aliased raster, caching the dvipng output in ~/.tex.cache for
> > efficiency.  For PS, we use tex + dvips + psfrag + latex + a patched
> > ps2epsi.  The latter is cumbersome, but it works.  In an ideal world,
> > we would simply use tex + dvips but embedding the postscript fragments
> > generated by dvips in arbitrary locations on the figure, but this has
> > proved challenging.
>
> Have you looked at how PyX (http://pyx.sourceforge.net/) handles things?
> They have excellent support for tex/latex labels and it seems to be
> implemented in a much "cleaner" way than you describe above. As far as I
> can see, they run a single TeX job containing all the strings from the
> current plot (see the texrunner class in pyx/text.py) and then parse the
> dvi output themselves (see pyx/dvifile.py)
>
> > Having our own dvi parser would be a nice solution.  As you noted, the
> > format isn't too complicated, except for the font handling and the
> > fact that you need your own bytecode processing engine to extract the
> > information.  We're waiting until Robert Kern has another boring
> > experiment to site through for this one.
>
> Well, PyX is GPLed so I don't see why you couldn't adopt their DVI
> parser. One thing you need to bear in mind if you are using TeX to
> generate PS output is that the resultant files will probably be
> unacceptable to many scientific journals without further processing. The
> production staff generally try to open the PS files in Adobe Illustrator
> and this causes multiple problems with files generated both by PyX and
> by dvips.=20

Why is this?

> The solution is to convert all fonts to outlines before=20
> submission (and also make sure all bbox coords are +ve). You can do this
> with recent versions of ghostscript:
>
>  gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=3Depswrite -dEPSFitPage \
>     -sOutputFile=3Dnew.eps old.eps

Coincidentally, I was just addressing the use of gs's epswrite this morning=
 on=20
the matplotlib-devel list. Unfortunately, epswrite will yield a file that=20
does not render well on screen. Given the increasing popularity of online=20
publication, it seems this approach for generating eps files would not be=20
acceptable to scientific journals either.

>
> I suppose I should introduce myself since I haven't posted to this list
> before. I've been looking at various python scientific plotting packages
> for the last few months. I'm currently using gnuplot (supplemented by
> bash or python scripting) for interactive use and quick hacks, together
> with PyX for publication-quality output. Matplotlib looks very
> interesting since I think it could potentially replace both gnuplot and
> PyX. The features it seemed to be lacking the last time I looked in any
> detail (v 0.70) were
>
> 1. Good, flexible support for reading data from files

Could you give an example? In my experience, datafiles tend to get so=20
complicated that all of Matlabs tools were useless. I end up writing code=20
specific to every type that isnt as simple as a few comment lines that are=
=20
ignored followed by a delimited array of data.



=2D-=20
Darren S. Dale

Bard Hall
Department of Materials Science and Engineering
Cornell University
Ithaca, NY. 14850

dd...@co...
http://people.ccmr.cornell.edu/~dd55/

Hi again,

up to now I've been using contourf() with the gray colormap so I hardly 
noticed this problem until now: the highest values of the contour do not get 
the right color.

You can see it on the 2 sample contour plots here:

http://nicolasgirard.nerim.net/cont.jpg

I've used the standard jet colormap. Note how the highest values are displayed 
in white, whereas they should have been displayed in red...

This is quite a critical problem for me, I'm ready to do anything if it can 
help solve it...

cheers,
nicolas

Hi list

On Wed, 2005-06-01 at 13:25 -0500, John Hunter wrote:
> >>>>> "Chris" == Chris Barker <Chr...@no...> writes:
> 
>     Chris> Wonderful! this is great news. How have you done it? Have
>     Chris> you written a DVI driver? or do you use TeX and associated
>     Chris> tools to create a bitmap and put that on the image? Or
>     Chris> something else?
> 
> For *Agg, we use tex + dvipng and load the output as a transparent,
> anti-aliased raster, caching the dvipng output in ~/.tex.cache for
> efficiency.  For PS, we use tex + dvips + psfrag + latex + a patched
> ps2epsi.  The latter is cumbersome, but it works.  In an ideal world,
> we would simply use tex + dvips but embedding the postscript fragments
> generated by dvips in arbitrary locations on the figure, but this has
> proved challenging.
> 

Have you looked at how PyX (http://pyx.sourceforge.net/) handles things?
They have excellent support for tex/latex labels and it seems to be
implemented in a much "cleaner" way than you describe above. As far as I
can see, they run a single TeX job containing all the strings from the
current plot (see the texrunner class in pyx/text.py) and then parse the
dvi output themselves (see pyx/dvifile.py)

> Having our own dvi parser would be a nice solution.  As you noted, the
> format isn't too complicated, except for the font handling and the
> fact that you need your own bytecode processing engine to extract the
> information.  We're waiting until Robert Kern has another boring
> experiment to site through for this one.

Well, PyX is GPLed so I don't see why you couldn't adopt their DVI
parser. One thing you need to bear in mind if you are using TeX to
generate PS output is that the resultant files will probably be
unacceptable to many scientific journals without further processing. The
production staff generally try to open the PS files in Adobe Illustrator
and this causes multiple problems with files generated both by PyX and
by dvips. The solution is to convert all fonts to outlines before
submission (and also make sure all bbox coords are +ve). You can do this
with recent versions of ghostscript:

 gs -dBATCH -dNOPAUSE -dSAFER -q -sDEVICE=epswrite -dEPSFitPage \
    -sOutputFile=new.eps old.eps

I suppose I should introduce myself since I haven't posted to this list
before. I've been looking at various python scientific plotting packages
for the last few months. I'm currently using gnuplot (supplemented by
bash or python scripting) for interactive use and quick hacks, together
with PyX for publication-quality output. Matplotlib looks very
interesting since I think it could potentially replace both gnuplot and
PyX. The features it seemed to be lacking the last time I looked in any
detail (v 0.70) were

1. Good, flexible support for reading data from files

2. Publication-quality text handling for math and accented characters
(i.e., full LaTeX support)

It looks like you have now addressed point 2 at least, so I've just
downloaded 0.81alpha from CVS and I'll see how it goes. The big
advantages matplotlib has over PyX in my opinion are a more intuitive
API and a larger/more-active developer pool and user base.  
   
Best wishes

Will

-- 
  Dr William Henney, Centro de Radioastronomía y Astrofísica,
  Universidad Nacional Autónoma de México, Campus Morelia

I had complained about not being able to set the legend fonts and John 
asked me to become a developer.  I haven't started working on it yet, 
but I plan to when I get back from a conference next week.  You may be 
in the same boat.

Here was John's response to me:

"Ryan" == Ryan Krauss <rya...@co...> writes:


    Ryan> Thanks Dale.  Based on that example, I can set the fontsize
    Ryan> from a script.  Is there a way to do it from the rc file?
    Ryan> It would be great to set it once with the rest of my font
    Ryan> preferences.

No, but it would not be difficult to add these parameters in rc.
Ready to become an mpl developer?  :-) 

Look at matplotlib/__init__.py to see how the rc params are
processed.  Add the ones you want and use them in legend.py, following
the example of Text or Line2D in matplotlib.text and matplotlib.line2d
respectively.

JDH

If you make progress on this before I do, let me know how you did it.

Ryan

Nicolas Girard wrote:

>On Thursday 02 June 2005 15:18, you wrote:
>  
>
>>Many of the font sizes can be specified in the .matplotlibrc file.
>>
>>    
>>
>Damn... I should have thought about it... but it doesn't work with the "too 
>large" fonts I'm left with: I changed
>
>  font.size           : medium
>
>into
>
>  font.size           : x-small
>
>in my ~/.matplotlibrc, but it changed nothing to the font used in the contours 
>ticks and in the colorbars ticks...
>
>Any other idea ?
>
>Nicolas
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Yahoo.
>Introducing Yahoo! Search Developer Network - Create apps using Yahoo!
>Search APIs Find out how you can build Yahoo! directly into your own
>Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>  
>

On Thursday 02 June 2005 15:18, you wrote:
> Many of the font sizes can be specified in the .matplotlibrc file.
>
Damn... I should have thought about it... but it doesn't work with the "too 
large" fonts I'm left with: I changed

  font.size           : medium

into

  font.size           : x-small

in my ~/.matplotlibrc, but it changed nothing to the font used in the contours 
ticks and in the colorbars ticks...

Any other idea ?

Nicolas

Hi again,

I find that all the fonts on my figures are too large ; up to now I've been 
modifying some of them using:

   from matplotlib.font_manager import FontProperties
   small=FontProperties( size="small" )
   ...
   title(...,fontproperties=small)

but there are still some fonts, e.g. on the ticks of the colorbars, that I 
couldn't figure out how to change ; anyway a better option, which would lead 
to less verbose commands, would be to specify default font properties for all 
the text of the figure.

Is there a way of doing it ?

Thanks in advance,
nicolas
 

On Thursday 02 June 2005 8:38 am, Nicolas Girard wrote:
> Hi all,
>
> on my box, using the savefig() function produces a bunch of annoying lines
> on the standard output, such as:
>
>   0 4.9375 8.0
>   200 18.96875 8.0
>   400 19.421875 8.0
>   600 18.9375 8.0
>   800 18.9375 8.0
>   1000 24.96875 8.0
>
> Is there any way of getting rid of these ?
>

Are you using a slightly dated CVS version, and are you making a ps or eps=
=20
file? I think there is a print statement we were using for debugging=20
somewhere in backend_ps that needs to be commented. I think the most recent=
=20
CVS is fixed.

Darren