matplotlib-devel Mailing List for matplotlib (Page 2)

On Thursday 24 April 2008 09:48:18 pm John Hunter wrote:
> On Thu, Apr 24, 2008 at 5:03 PM, Eric Firing <ef...@ha...> wrote:
> > Darren,
> >
> > It is open for discussion. Here are some factors:
> >
> > 1) In my experience, numpy is easy to build from source--easier than
> > matplotlib.
>
> This is my view too -- if you rely on or can build svn mpl, I seen no
> reason why you can't also rely on/build svn numpy since it is a much
> easier build. If mpl builds, numpy svn is pretty much guaranteed to
> build on any platform.
>
> If I am missing something Darren, please let me know, but in my
> regular workflow, I pretty much assume I can bild svn ipython, numpy
> and mpl, and hopefully scipy.
I have been developing a data acquisition and analysis program for my lab, and 
we are actually in the process of using it it this week and next to run 
experiments with our visiting scientists. I've been running matplotlib from 
svn for as long as I can remember and hadn't anticipated trouble. I guess I 
just wasn't reading the dev list closely enough since I rely on the trunk for 
daily use.
Maybe we should consider cutting a transitional prelease at some point before 
additional big changes are made, so those of us who have already transitioned 
our code to the new codebase have a reference build we can install when we 
run into trouble on the trunk?

On Thu, Apr 24, 2008 at 5:03 PM, Eric Firing <ef...@ha...> wrote:
> Darren,
>
> It is open for discussion. Here are some factors:
>
> 1) In my experience, numpy is easy to build from source--easier than
> matplotlib.
This is my view too -- if you rely on or can build svn mpl, I seen no
reason why you can't also rely on/build svn numpy since it is a much
easier build. If mpl builds, numpy svn is pretty much guaranteed to
build on any platform.
If I am missing something Darren, please let me know, but in my
regular workflow, I pretty much assume I can bild svn ipython, numpy
and mpl, and hopefully scipy.
JDH

Darren Dale wrote:
> On Thursday 24 April 2008 03:09:43 pm John Hunter wrote:
>> On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
>>> Darren,
>>>
>>> In an earlier thread on matplotlib-users, when this first came up, John
>>> noted that numpy svn should be required for present mpl svn, so
>>> instead of fixing the attempted workaround for 1.04 I took it out and
>>> instead put a numpy version check in matplotlib.__init__.
>> Just to make clear my thinking on this: since the svn trunk of mpl is
>> a major refactoring and will be a major point jump when we release it
>> (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we
>> can rely on all the nice features and fixes that have gone into that
>> release.
> 
> I've been installing numpy through various package managers and now I'll need 
> to figure out how to configure the build on fedora, ubuntu and gentoo in 
> order to use svn matplotlib. Was it a mistake for me to develop my 
> application using the matplotlib trunk? If I go through the trouble of 
> configuring the build environments for numpy on these various OS's, am I 
> going to discover that the numpy trunk is not backward compatible and is 
> causing problems with other applications? I know my own difficulties are not 
> sufficient reason to alter the development path of our fine library, but I 
> think this might be a mistake.
Darren,
It is open for discussion. Here are some factors:
1) In my experience, numpy is easy to build from source--easier than 
matplotlib.
2) The numpy 1.1 release is coming soon--on the order of a week. I 
don't know how much that will help you. Maybe not much until distro 
packages catch up, which can take a long time.
3) There have been a lot of bug fixes between numpy 1.04 and 1.1. The 
main area of *slight* incompatibility is in the masked array package. 
The main practical difference is that some import forms that worked with 
1.04 do not work with 1.1; e.g. you can't import ma from numpy.core 
because that is not where it is now, and it is sub-package, not a file. 
 The ma internals are quite different (a masked array is now a subclass 
of ndarray), and the overall implementation is much improved, but 
functions and methods are highly compatible.
Although I am sympathetic to the problems involved in making changes of 
this sort, I am also sympathetic to the problems of trying to keep 
something like mpl working with multiple versions of components like the 
numeric library. There were a lot of bugs and holes in the old 
numpy.ma. To me, it is a relief to be able to stick to the new version 
and forget about the limitations and quirks of the old. Ideally, it will 
mean that all of us can spend more time thinking about how to improve 
mpl and less time in duplicate testing and coming up with workarounds.
Eric

Hum, a quite common discussion (we have had it at the nipy sprint, for
instance). My feeling is that you want to avoid depending on SVN
versions, unless there is a huge gain. The reason is that you loose
tester and potential contributors. In addition it makes it harder to get
the whole stack in a consistent shape because everything becomes a moving
target.
My 2 cents,
Gaël

On Thursday 24 April 2008 03:09:43 pm John Hunter wrote:
> On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
> > Darren,
> >
> > In an earlier thread on matplotlib-users, when this first came up, John
> > noted that numpy svn should be required for present mpl svn, so
> > instead of fixing the attempted workaround for 1.04 I took it out and
> > instead put a numpy version check in matplotlib.__init__.
>
> Just to make clear my thinking on this: since the svn trunk of mpl is
> a major refactoring and will be a major point jump when we release it
> (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we
> can rely on all the nice features and fixes that have gone into that
> release.
I've been installing numpy through various package managers and now I'll need 
to figure out how to configure the build on fedora, ubuntu and gentoo in 
order to use svn matplotlib. Was it a mistake for me to develop my 
application using the matplotlib trunk? If I go through the trouble of 
configuring the build environments for numpy on these various OS's, am I 
going to discover that the numpy trunk is not backward compatible and is 
causing problems with other applications? I know my own difficulties are not 
sufficient reason to alter the development path of our fine library, but I 
think this might be a mistake.

On Thu, Apr 24, 2008 at 3:32 PM, Eric Firing <ef...@ha...> wrote:
> Agreed. If there were a meta-class usage that was crystal-clear after a
> little inspection, and that actually made the code easier to understand and
> maintain, I would consider it.
>
> I know that when we talked in Kona I was complaining about decorators, but
> they are here to stay, and as long as they are not too tricky they can be
> fine. The @staticmethod form is an improvement over the non-decorator
> equivalent, an assignment at the bottom of the method. I would be happy to
> see Mike's commented-out @staticmethod lines uncommented, and the
> corresponding assignments at the bottom of the method deleted, for example.
>
> Requiring 2.4 would also let us remove the subprocess module--not a big
> deal, but an incremental simplification of the mpl package.
All these sound like good suggestions to me...
JDH

John Hunter wrote:
> On Thu, Apr 24, 2008 at 2:21 PM, Eric Firing <ef...@ha...> wrote:
> 
>> On a related note, what about python >= 2.4 instead of 2.3? This is not
>> something I have a strong opinion about, but I think it might also be a
>> reasonable time to let 2.4 be the minimum requirement.
> 
> I think python 2.4 is totally reasonable for the 0.98 release, though
> I am still prone to avoiding certain magic like meta-classes where
> possible.
> 
> JDH
Agreed. If there were a meta-class usage that was crystal-clear after a 
little inspection, and that actually made the code easier to understand 
and maintain, I would consider it.
I know that when we talked in Kona I was complaining about decorators, 
but they are here to stay, and as long as they are not too tricky they 
can be fine. The @staticmethod form is an improvement over the 
non-decorator equivalent, an assignment at the bottom of the method. I 
would be happy to see Mike's commented-out @staticmethod lines 
uncommented, and the corresponding assignments at the bottom of the 
method deleted, for example.
Requiring 2.4 would also let us remove the subprocess module--not a big 
deal, but an incremental simplification of the mpl package.
Eric

On Thu, Apr 24, 2008 at 2:21 PM, Eric Firing <ef...@ha...> wrote:
> On a related note, what about python >= 2.4 instead of 2.3? This is not
> something I have a strong opinion about, but I think it might also be a
> reasonable time to let 2.4 be the minimum requirement.
I think python 2.4 is totally reasonable for the 0.98 release, though
I am still prone to avoiding certain magic like meta-classes where
possible.
JDH

On Thu, Apr 24, 2008 at 2:21 PM, Eric Firing <ef...@ha...> wrote:
> On a related note, what about python >= 2.4 instead of 2.3? This is not
> something I have a strong opinion about, but I think it might also be a
> reasonable time to let 2.4 be the minimum requirement.
As a point of reference, NumPy 1.2 will require python >= 2.4 and so
will the SciPy 0.7 release.
-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/

John Hunter wrote:
> On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
>> Darren,
>>
>> In an earlier thread on matplotlib-users, when this first came up, John
>> noted that numpy svn should be required for present mpl svn, so
>> instead of fixing the attempted workaround for 1.04 I took it out and
>> instead put a numpy version check in matplotlib.__init__.
> 
> Just to make clear my thinking on this: since the svn trunk of mpl is
> a major refactoring and will be a major point jump when we release it
> (0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we
> can rely on all the nice features and fixes that have gone into that
> release.
> 
> JDH
I agree completely!
On a related note, what about python >= 2.4 instead of 2.3? This is not 
something I have a strong opinion about, but I think it might also be a 
reasonable time to let 2.4 be the minimum requirement.
Eric

On Thu, Apr 24, 2008 at 1:32 PM, Eric Firing <ef...@ha...> wrote:
> Darren,
>
> In an earlier thread on matplotlib-users, when this first came up, John
> noted that numpy svn should be required for present mpl svn, so
> instead of fixing the attempted workaround for 1.04 I took it out and
> instead put a numpy version check in matplotlib.__init__.
Just to make clear my thinking on this: since the svn trunk of mpl is
a major refactoring and will be a major point jump when we release it
(0.98), this is a good time to get onto numpy 1.1 (ie numpy svn) so we
can rely on all the nice features and fixes that have gone into that
release.
JDH

Darren,
In an earlier thread on matplotlib-users, when this first came up, John 
 noted that numpy svn should be required for present mpl svn, so 
instead of fixing the attempted workaround for 1.04 I took it out and 
instead put a numpy version check in matplotlib.__init__.
Eric
Darren Dale wrote:
> It looks like the recent modification to transforms.py to update datalims only 
> when valid data are available is broken for numpy-1.04. In 
> tranforms.Bbox.update_from_data_xy, with numpy-1.04, the following line:
> 
> xym = ma.masked_where(~npy.isfinite(xy), xy)
> 
> fails with:
> 
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2805, in 
> plot
> self.add_line(line)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1165, in 
> add_line
> self._update_line_limits(line)
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1173, in 
> _update_line_limits
> self.update_datalim( xydata )
> File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1221, in 
> update_datalim
> self.dataLim.update_from_data_xy(xys, self.ignore_existing_data_limits)
> File "/usr/lib64/python2.5/site-packages/matplotlib/transforms.py", line 
> 699, in update_from_data_xy
> xym = ma.masked_where(~npy.isfinite(xy), xy)
> File "/usr/lib64/python2.5/site-packages/numpy/core/ma.py", line 641, in 
> __array_wrap__
> domain = ufunc_domain[func]
> KeyError: <ufunc 'isfinite'>
> 
> 
> It looks like isfinite doesnt like getting a masked array as input. Is xy 
> always a masked array? If so, maybe that line could look like:
> 
> xym = ma.masked_where(~npy.isfinite(xy.data), xy)
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Mike,
One of your cleanups might have introduced a problem?
Eric
Updated to revision 5071.
efiring@manini:~/programs/py/mpl/mpl_trunk$ psb
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98pre
 python: 2.5.1 (r251:54863, Mar 7 2008, 03:41:45) [GCC
 4.1.2 (Ubuntu 4.1.2-0ubuntu4)]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.1.0.dev5061
 freetype2: 9.10.3
OPTIONAL BACKEND DEPENDENCIES
 libpng: 1.2.15beta5
 Tkinter: Tkinter: 50704, Tk: 8.4, Tcl: 8.4
 wxPython: 2.8.1.1
 * WxAgg extension not required for wxPython >= 2.8
 Gtk+: gtk+: 2.10.11, glib: 2.12.11, pygtk: 2.10.4,
 pygobject: 2.12.3
 Qt: Qt: 3.3.7, PyQt: 3.17
 Qt4: Qt: 4.2.2, PyQt4: 4.1
 Cairo: 1.2.0
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: present, version unknown
 pytz: 3371
OPTIONAL USETEX DEPENDENCIES
 dvipng: 1.9
 ghostscript: 8.15.4
 latex: 3.141592
 pdftops: 3.00
EXPERIMENTAL CONFIG PACKAGE DEPENDENCIES
 configobj: 4.4.0
 enthought.traits: matplotlib will provide
[Edit setup.cfg to suppress the above messages]
============================================================================
running build
running build_py
copying lib/matplotlib/__init__.py -> build/lib.linux-i686-2.5/matplotlib
copying lib/matplotlib/mathtext.py -> build/lib.linux-i686-2.5/matplotlib
copying lib/matplotlib/mlab.py -> build/lib.linux-i686-2.5/matplotlib
copying lib/matplotlib/backends/backend_wx.py -> 
build/lib.linux-i686-2.5/matplotlib/backends
copying lib/matplotlib/mpl-data/matplotlibrc -> 
build/lib.linux-i686-2.5/matplotlib/mpl-data
copying lib/matplotlib/mpl-data/matplotlib.conf -> 
build/lib.linux-i686-2.5/matplotlib/mpl-data
running build_ext
building 'matplotlib.ft2font' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC -I/usr/include/freetype2 -I/usr/local/include 
-I/usr/include -I. -I/usr/include/python2.5 -c src/ft2font.cpp -o 
build/temp.linux-i686-2.5/src/ft2font.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
g++ -pthread -shared -Wl,-O1 build/temp.linux-i686-2.5/src/ft2font.o 
build/temp.linux-i686-2.5/src/mplutils.o 
build/temp.linux-i686-2.5/CXX/cxx_extensions.o 
build/temp.linux-i686-2.5/CXX/IndirectPythonInterface.o 
build/temp.linux-i686-2.5/CXX/cxxsupport.o 
build/temp.linux-i686-2.5/CXX/cxxextensions.o -L/usr/local/lib 
-lfreetype -lz -lstdc++ -lm -o 
build/lib.linux-i686-2.5/matplotlib/ft2font.so
building 'matplotlib.ttconv' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. 
-I/usr/include/python2.5 -c src/_ttconv.cpp -o 
build/temp.linux-i686-2.5/src/_ttconv.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC -I/usr/local/include -I/usr/include -I. 
-I/usr/include/python2.5 -c ttconv/pprdrv_tt.cpp -o 
build/temp.linux-i686-2.5/ttconv/pprdrv_tt.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
g++ -pthread -shared -Wl,-O1 build/temp.linux-i686-2.5/src/_ttconv.o 
build/temp.linux-i686-2.5/ttconv/pprdrv_tt.o 
build/temp.linux-i686-2.5/ttconv/pprdrv_tt2.o 
build/temp.linux-i686-2.5/ttconv/ttutil.o -L/usr/local/lib -o 
build/lib.linux-i686-2.5/matplotlib/ttconv.so
building 'matplotlib._path' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include -Isrc 
-Iagg24/include -I. -I/usr/include/python2.5 -c agg24/src/agg_curves.cpp 
-o build/temp.linux-i686-2.5/agg24/src/agg_curves.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include -Isrc 
-Iagg24/include -I. -I/usr/include/python2.5 -c src/path.cpp -o 
build/temp.linux-i686-2.5/src/path.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
g++ -pthread -shared -Wl,-O1 
build/temp.linux-i686-2.5/agg24/src/agg_curves.o 
build/temp.linux-i686-2.5/agg24/src/agg_bezier_arc.o 
build/temp.linux-i686-2.5/agg24/src/agg_trans_affine.o 
build/temp.linux-i686-2.5/agg24/src/agg_vcgen_stroke.o 
build/temp.linux-i686-2.5/CXX/cxx_extensions.o 
build/temp.linux-i686-2.5/CXX/IndirectPythonInterface.o 
build/temp.linux-i686-2.5/CXX/cxxsupport.o 
build/temp.linux-i686-2.5/CXX/cxxextensions.o 
build/temp.linux-i686-2.5/src/path.o -L/usr/local/lib -lpng12 -lz 
-lstdc++ -lm -o build/lib.linux-i686-2.5/matplotlib/_path.so
building 'matplotlib.backends._backend_agg' extension
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O2 -Wall 
-Wstrict-prototypes -fPIC 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include 
-I/usr/include/libpng12 -I/usr/local/include -I/usr/include -I. 
-I/usr/local/lib/python2.5/site-packages/numpy/core/include -Isrc 
-Iagg24/include -I. -I/usr/include/freetype2 -I/usr/local/include 
-I/usr/include -I. -I/usr/include/python2.5 -c src/_image.cpp -o 
build/temp.linux-i686-2.5/src/_image.o
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for 
Ada/C/ObjC but not for C++
/usr/include/libpng12/pngconf.h:317: error: expected constructor, 
destructor, or type conversion before ‘.’ token
/usr/include/libpng12/pngconf.h:318: error: ‘__dont__’ does not name a type
error: command 'gcc' failed with exit status 1

It looks like the recent modification to transforms.py to update datalims only 
when valid data are available is broken for numpy-1.04. In 
tranforms.Bbox.update_from_data_xy, with numpy-1.04, the following line:
xym = ma.masked_where(~npy.isfinite(xy), xy)
fails with:
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 2805, in 
plot
 self.add_line(line)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1165, in 
add_line
 self._update_line_limits(line)
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1173, in 
_update_line_limits
 self.update_datalim( xydata )
 File "/usr/lib64/python2.5/site-packages/matplotlib/axes.py", line 1221, in 
update_datalim
 self.dataLim.update_from_data_xy(xys, self.ignore_existing_data_limits)
 File "/usr/lib64/python2.5/site-packages/matplotlib/transforms.py", line 
699, in update_from_data_xy
 xym = ma.masked_where(~npy.isfinite(xy), xy)
 File "/usr/lib64/python2.5/site-packages/numpy/core/ma.py", line 641, in 
__array_wrap__
 domain = ufunc_domain[func]
KeyError: <ufunc 'isfinite'>
It looks like isfinite doesnt like getting a masked array as input. Is xy 
always a masked array? If so, maybe that line could look like:
xym = ma.masked_where(~npy.isfinite(xy.data), xy)

Paul Kienzle wrote:
> Hi,
>
> The superscripts in mpl don't seem to be placed at the correct height for
> small fonts. The y-tics on the attached plot shows this. The effect is
> similar in svg and pdf backends.
> 
Thanks. When looking up the x-height, the code was not taking the font 
size into account. This has been fixed on the branch and trunk.
> I'm using 0.91.2 because the latest svn version gives me a KeyError for
> ufunc isfinite.
> 
Can you provide the full traceback here so we can diagnose and fix this 
problem? The only reference to isfinite seems to be in the PDF backend, 
which is working for me, and is identical in 0.91.2 and trunk in that 
respect. There is probably a more complex Numpy version interaction 
going on.
Cheers,
Mike
> 	- Paul
>
> 
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi,
The superscripts in mpl don't seem to be placed at the correct height for
small fonts. The y-tics on the attached plot shows this. The effect is
similar in svg and pdf backends.
I'm using 0.91.2 because the latest svn version gives me a KeyError for
ufunc isfinite.
	- Paul

On 2008年4月22日 15:41:26 -0400, Michael Droettboom wrote:
> My concern with subpixel rendering has always been that it's fine for
> interactive use, but for producing plots that may end up on someone
> else's screen or on a printer, it can actually make matters much worse.
Naturally.
As such, cairo lets you explicitly choose what you want to draw by
setting one of the following values in your font options:
 CAIRO_ANTIALIAS_NONE: Use a bilevel alpha mask.
 CAIRO_ANTIALIAS_GRAY: Perform single-color antialiasing (using
 shades of gray for black text on a white background, for example).
 CAIRO_ANTIALIAS_SUBPIXEL: Perform antialiasing by taking
 advantage of the order of subpixel elements on devices
 such as LCD panels
And most importantly, the default value is as follows:
 CAIRO_ANTIALIAS_DEFAULT: Use the default antialiasing for
 the subsystem and target device
So, (excepting bugs), you should really have to go out of your way to
get cairo to do the wrong thing here.
-Carl

My concern with subpixel rendering has always been that it's fine for 
interactive use, but for producing plots that may end up on someone 
else's screen or on a printer, it can actually make matters much worse.
Agg (well freetype really) could do subpixel font rendering as well, but 
I deliberately stayed away from it last time I looked at fonts. We 
could have some mechanism to determine whether the render is intended 
for a GUI or a file, but that would have to be dealt with carefully so 
as not to introduce more backend selection and context related problems.
Cheers,
Mike
Darren Dale wrote:
> On Tuesday 22 April 2008 02:54:09 pm Eric Firing wrote:
> 
>> In case any devels are interested in making more backends work on the
>> trunk:
>>
>> Running examples/backend_driver.py yields quite a few svg plots that are
>> incorrect, with things like colorbars missing their colors.
>>
>> The cairo backend does better, but also needs a little work. Cairo is
>> looking more interesting with the latest release; the notes say that eps
>> output is now supported.
>> 
>
> Also, sibpixel rendering of fonts is supported in the new Cairo. On an LCD 
> monitor, fonts look sharper with Cairo than they do with AGG.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save 100ドル. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Tuesday 22 April 2008 02:54:09 pm Eric Firing wrote:
> In case any devels are interested in making more backends work on the
> trunk:
>
> Running examples/backend_driver.py yields quite a few svg plots that are
> incorrect, with things like colorbars missing their colors.
>
> The cairo backend does better, but also needs a little work. Cairo is
> looking more interesting with the latest release; the notes say that eps
> output is now supported.
Also, sibpixel rendering of fonts is supported in the new Cairo. On an LCD 
monitor, fonts look sharper with Cairo than they do with AGG.

In case any devels are interested in making more backends work on the trunk:
Running examples/backend_driver.py yields quite a few svg plots that are 
incorrect, with things like colorbars missing their colors.
The cairo backend does better, but also needs a little work. Cairo is 
looking more interesting with the latest release; the notes say that eps 
output is now supported.
Eric

This is inherent; mpl 0.90.1 is permanently incompatible with numpy 1.1, 
short of each user making the change suggested below. The earliest mpl 
that should work with numpy 1.1 is 0.91.2.
The change in masked array module is a major reason why numpy is getting 
a version bump to 1.1.0 instead of 1.0.5.
Eric
Michael Droettboom wrote:
> I will forward it to the matplotlib-devel mailing list on your behalf.
> 
> Cheers,
> Mike
> 
> lorenzo bolla wrote:
>> Hello,
>>
>> the latest svn numpy version 1.1.0.dev5061 does not work with 
>> matplotlib 0.90.1 (version shipped with enthought distribution), 
>> unless a change in 
>> Python25/Lib/site-packages/matplotlib-0.90.1.0003-py2.5-win32.egg/matplotlib/numerix/ma/__init__.py 
>> is done:
>>
>> $ diff __init__.py.orig __init__.py
>> 12c12
>> < from numpy.core.ma <http://numpy.core.ma> import *
>> ---
>>> from numpy.ma <http://numpy.ma> import *
>> Maybe this should be forwarded to the pylab mailing list, but I'm not 
>> subscribed there...
>>
>> L.
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Numpy-discussion mailing list
>> Num...@sc...
>> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>> 
> 

I will forward it to the matplotlib-devel mailing list on your behalf.
Cheers,
Mike
lorenzo bolla wrote:
> Hello,
>
> the latest svn numpy version 1.1.0.dev5061 does not work with 
> matplotlib 0.90.1 (version shipped with enthought distribution), 
> unless a change in 
> Python25/Lib/site-packages/matplotlib-0.90.1.0003-py2.5-win32.egg/matplotlib/numerix/ma/__init__.py 
> is done:
>
> $ diff __init__.py.orig __init__.py
> 12c12
> < from numpy.core.ma <http://numpy.core.ma> import *
> ---
> > from numpy.ma <http://numpy.ma> import *
>
> Maybe this should be forwarded to the pylab mailing list, but I'm not 
> subscribed there...
>
> L.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Numpy-discussion mailing list
> Num...@sc...
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Stéfan,
OK, I see some differences now, and it looks like it is related to 
antialiasing and the rendering of patch boundaries. I have run into 
this sort of thing before, where depending on how patch edges are 
handled, and depending on the particular renderer and viewer 
combination, antialiasing can make the result better or worse. To make 
things even more confusing, a combination that looks good with alpha=1 
can look bad with alpha<1.
Linewidth of 1 is a bit drastic, and can significantly shift the 
perceived boundaries. Maybe a smaller value would be adequate. I 
played with all this a long time ago before settling on linewidth of 
zero with antialiasing turned on, which seemed to be a good compromise. 
 Either I was wrong, or the Agg rendering is different in Agg 2.4.
One of the strange things here is that even when I set the antialiased 
kwarg to False, I still seem to be getting antialiasing.
The lack of effect of the antialiasing kwarg on my system looks like a 
definite bug that requires investigation.
To be continued, but not right now.
Eric
Stéfan van der Walt wrote:
> On 20/04/2008, Eric Firing <ef...@ha...> wrote:
>> I don't see any contour lines; I see only the boundaries between patches.
>> In other words, the plot looks the way I would expect it to. This is with
>> evince or gv on a linux machine. (Both fail when trying to blow up the plot
>> to 400%, but work at 200%.)
> 
> Attached is the script that generates the contour plot I'm interested
> in. A PNG cropped from the PS onscreen is at
> 
> http://mentat.za.net/refer/contour_zoom.png
> 
> It's small, but the line should be clearly visible.
> 
>> My sense is that there is an optical illusion effect making the boundaries
>> look somewhat line-like, but it doesn't sound like this is what you are
>> talking about, so I am baffled.
> 
> Could be -- maybe an interpolation effect? Odd thing is that the
> lines are differently coloured. In fact, I can get *only* the lines
> to render by commenting out certain lines in contour.py.
> 
>> Do you see the problem if you run contourf_demo.py and use the gui to
>> generate png, pdf, and ps files from figure 1? I still can't see any sign
>> of it anywhere.
> 
> I see contour lines, as shown here:
> 
> http://mentat.za.net/refer/contour_demo.png
> 
>> Would you send a png file generated with and without your workaround,
>> please? That should get around any differences in postscript interpreters.
> 
> They are here:
> 
> http://mentat.za.net/refer/contours_without_patch.png
> http://mentat.za.net/refer/contours_with_patch.png
> 
>> It sounds like you are seeing something fairly subtle that I am having a
>> hard time seeing, and that is new with the transforms branch.
> 
> I don't want to waste your time further with this problem, so if you
> think the above png's look fine then I'll just use my workaround. It
> might be a problem very specific to my setup.
> 
> Thanks for your time,
> Stéfan

And the attachment...
On 20/04/2008, Eric Firing <ef...@ha...> wrote:

On 20/04/2008, Eric Firing <ef...@ha...> wrote:
> I don't see any contour lines; I see only the boundaries between patches.
> In other words, the plot looks the way I would expect it to. This is with
> evince or gv on a linux machine. (Both fail when trying to blow up the plot
> to 400%, but work at 200%.)
Attached is the script that generates the contour plot I'm interested
in. A PNG cropped from the PS onscreen is at
http://mentat.za.net/refer/contour_zoom.png
It's small, but the line should be clearly visible.
> My sense is that there is an optical illusion effect making the boundaries
> look somewhat line-like, but it doesn't sound like this is what you are
> talking about, so I am baffled.
Could be -- maybe an interpolation effect? Odd thing is that the
lines are differently coloured. In fact, I can get *only* the lines
to render by commenting out certain lines in contour.py.
> Do you see the problem if you run contourf_demo.py and use the gui to
> generate png, pdf, and ps files from figure 1? I still can't see any sign
> of it anywhere.
I see contour lines, as shown here:
http://mentat.za.net/refer/contour_demo.png
> Would you send a png file generated with and without your workaround,
> please? That should get around any differences in postscript interpreters.
They are here:
http://mentat.za.net/refer/contours_without_patch.png
http://mentat.za.net/refer/contours_with_patch.png
> It sounds like you are seeing something fairly subtle that I am having a
> hard time seeing, and that is new with the transforms branch.
I don't want to waste your time further with this problem, so if you
think the above png's look fine then I'll just use my workaround. It
might be a problem very specific to my setup.
Thanks for your time,
Stéfan