matplotlib-users Mailing List for matplotlib (Page 11)

On Wed, 2005年06月01日 at 05:12 -0700, matplotlib-users-
re...@li... wrote:
> I have started looking at the code and did not quite understand what I 
> found:
> 
> backends/backend_gtk.py has a class FigureCanvasGTK. Its method 
> 'expose_event' is responsible for redrawing.
> In the situation I described, when I leave an opened menu that overlaps 
> the graph, the expose_event is properly called, but the widget is not 
> redrawn. If DBL_BUFFER is set (which it is), the widget is only redrawn, 
> if self._draw_pixmap is set to True. 
Thats not true, see below.
> Of course, this variable is not set 
> to True when GTK closes a menu but only when matplotlib requests a 
> redraw. So, in conclusion, no redraw happens.
> 
> After consulting the PyGTK reference I tried to reactivate double 
> buffering, which is turned of in the backend_gtk.py by the command
> 
> self.set_double_buffered(False)
> 
> I wonder why you set this? Do you want to provide your own double 
> buffering? Why? If you set this value to True, everything will be fine.
> 
> Best regards,
> 
> Niklas Volbers.
Why do we have self.set_double_buffered(False)?
Its been that way for as long as I can remember, I think John wrote the
original code, he may remember the actual reasons.
My guess is because of printing. backend_gtk has two basic functions -
to plot to the display and to plot to a file. If you 
set_double_buffered(False) you can draw to a Pixmap and use the pixmap
to draw to both the screen and to a jpg or png file.
If you draw direct to a gdk.Window you can only save to a file if the
gdk.Window is mapped; if the window is minimised or not yet realized the
print will fail. The 'savefig()' command would not work if called before
'show()'.
expose-events:
If the window is resized or draw() is called self._draw_pixmap is set to
True and the whole figure is redrawn to the Pixmap.
self.window.set_back_pixmap() is then called to set the window
background to the Pixmap. Then if an expose event occurs, without the
window being resized or draw() being called, matplotlib does not need to
do anything. GTK+ handles it for us by automatically filling an exposed
window with its background, which is our plot.
This is how it works for GTK+/PyGTK 2.4. However, something changed in
2.6 and it no longer always draws the widgets background. I think this
is a bug, however after rereading the gdk_window_set_back_pixmap()
manual page I notice it says:
"The windowing system will normally fill a window with its background
when the window is obscured then exposed, and when you call
gdk_window_clear()"
What is "normally" supposed to mean? It not something you can rely on,
so it may just as well be "never". I think that the documentation is
unclear and opened a documentation bug report
http://bugzilla.gnome.org/show_bug.cgi?id=306214
I also found a bug report very similar to the problem experienced in
matplotlib
http://bugzilla.gnome.org/show_bug.cgi?id=161561
its been resolved as 'fixed', so GTK+ 2.6.1 (with the fix applied) may
work OK, and it may just have been a 2.6.0 problem.
Regards,
Steve
Send instant messages to your online friends http://au.messenger.yahoo.com 

Hi All,
On Thursday 02 June 2005 6:34 pm, William Henney wrote:
>
> 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=3Depswrite -dEPSFitPage \
> > > -sOutputFile=3Dnew.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.
John has gotten us most of the way there. I think the problem I am having=20
embedding these LaTeX-generated eps files is related to the fact that the=20
postscript constructs in the image are not isolated from the main document,=
=20
dvips is not creative in naming them, and therefore the font properties (or=
=20
encoding, or something) are being corrupted.
Since I also have limited time, I could use epswrite for now. The resulting=
=20
figures are not fantastic on screen, (I already had smooth line art enabled=
=20
in Adobe Reader), but marginal improvements can be had by increasing the=20
viewer's resolution. The print version is still good. Since epswrite=20
basically converts the fonts to an image anyway, I would like to propose on=
e=20
last time that if text.usetex is true, we draw the text as an image in eps,=
=20
just until the better solution becomes available. That way the screen versi=
on=20
would still look good, the entire picture would open in Adobe illustrator,=
=20
how big would the files be?
I am going to add an option to use LaTeX instead of TeX to render the text.=
=20
TeX is about 30% faster than LaTeX, but ever since John pointed out how muc=
h=20
the bitstream fonts suck, I cant help but notice how much the bitstream fon=
ts=20
suck. Right now I am using the pslatex package, and these fonts are quite a=
n=20
improvement. The txfonts package is also nice. How do people feel about two=
=20
more rc options: one to select tex or latex, and another to choose the font=
=20
package?

Hi Fernando
On 6/2/05, Fernando Perez <Fer...@co...> wrote:
> scipy's read_array, while not identical to gnuplot's, isn't bad at all:
>=20
Yes, that looks like just what I want. Thanks!
Will
--=20
 Dr William Henney, Centro de Radioastronom=EDa y Astrof=EDsica,
 Universidad Nacional Aut=F3noma de M=E9xico, Campus Morelia

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