matplotlib-devel Mailing List for matplotlib (Page 5)

On 2009年05月18日 20:05, Darren Dale wrote:
> On Mon, May 18, 2009 at 8:41 PM, Robert Kern <rob...@gm...
> <mailto:rob...@gm...>> wrote:
>
> On 2009年05月18日 19:07, Andrew Straw wrote:
> > I've been hacking away at adding support for "dropped spines" to MPL
> > (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> > have come to the conclusion that there is a fundamental issue in the
> > code base that the traits package has solved -- many values that
> depend
> > on other values with complicated stuff that happens when one of the
> > parent values changes. For example, the location of the text from the
> > xaxis depends on the padding value in addition to the xaxis location.
> > Now I'm trying to add another element to the mix -- namely an
> axis spine
> > that can change location -- and things are going to spiral into a
> > (further) collection of special-cased updates unless there's some
> > reworking of the infrastructure.
> >
> > So, the question is, should I attempt to use traits for this? I guess
> > that I won't have the time to re-write the entire code base to use
> > traits, but I'd like make a stab a stab at dropped spine support with
> > the knowledge that, should I be successful, there's at least a
> chance we
> > would again ship traits with MPL. I imagine we could
> incrementally move
> > more and more to traits if I'm successful, particularly now that
> we have
> > the beginnings of a unit test infrastructure (thanks James!).
>
> If you do, *please* either depend on Traits or, if you must include
> the code in
> matplotlib itself, stick it under matplotlib's namespace.
>
>
> We stopped shipping traits with mpl a long time ago, when that issue was
> identified.
But part of that calculation was that Traits wasn't being used for anything 
non-experimental. Since that is being revisited, and since you still do 
distribute other packages like dateutils and pytz (which also cause similar 
installation headaches) the same way, I would like this to be kept in mind.
> I really don't want to
> go back to having to fix people's broken installations again.
>
>
> Was that comment really necessary?
Was it really offensive? People would install matplotlib, then they would try to 
install other parts of ETS, the ETS stuff wouldn't work, thus they had a broken 
installation. I do not want to go back to having to fix their broken 
installations. This isn't a jab at the matplotlib team.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

On Mon, May 18, 2009 at 8:41 PM, Robert Kern <rob...@gm...> wrote:
> On 2009年05月18日 19:07, Andrew Straw wrote:
> > I've been hacking away at adding support for "dropped spines" to MPL
> > (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> > have come to the conclusion that there is a fundamental issue in the
> > code base that the traits package has solved -- many values that depend
> > on other values with complicated stuff that happens when one of the
> > parent values changes. For example, the location of the text from the
> > xaxis depends on the padding value in addition to the xaxis location.
> > Now I'm trying to add another element to the mix -- namely an axis spine
> > that can change location -- and things are going to spiral into a
> > (further) collection of special-cased updates unless there's some
> > reworking of the infrastructure.
> >
> > So, the question is, should I attempt to use traits for this? I guess
> > that I won't have the time to re-write the entire code base to use
> > traits, but I'd like make a stab a stab at dropped spine support with
> > the knowledge that, should I be successful, there's at least a chance we
> > would again ship traits with MPL. I imagine we could incrementally move
> > more and more to traits if I'm successful, particularly now that we have
> > the beginnings of a unit test infrastructure (thanks James!).
>
> If you do, *please* either depend on Traits or, if you must include the
> code in
> matplotlib itself, stick it under matplotlib's namespace.
We stopped shipping traits with mpl a long time ago, when that issue was
identified.
> I really don't want to
> go back to having to fix people's broken installations again.
>
Was that comment really necessary?
Darren

On 2009年05月18日 19:07, Andrew Straw wrote:
> I've been hacking away at adding support for "dropped spines" to MPL
> (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> have come to the conclusion that there is a fundamental issue in the
> code base that the traits package has solved -- many values that depend
> on other values with complicated stuff that happens when one of the
> parent values changes. For example, the location of the text from the
> xaxis depends on the padding value in addition to the xaxis location.
> Now I'm trying to add another element to the mix -- namely an axis spine
> that can change location -- and things are going to spiral into a
> (further) collection of special-cased updates unless there's some
> reworking of the infrastructure.
>
> So, the question is, should I attempt to use traits for this? I guess
> that I won't have the time to re-write the entire code base to use
> traits, but I'd like make a stab a stab at dropped spine support with
> the knowledge that, should I be successful, there's at least a chance we
> would again ship traits with MPL. I imagine we could incrementally move
> more and more to traits if I'm successful, particularly now that we have
> the beginnings of a unit test infrastructure (thanks James!).
If you do, *please* either depend on Traits or, if you must include the code in 
matplotlib itself, stick it under matplotlib's namespace. I really don't want to 
go back to having to fix people's broken installations again.
-- 
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
 -- Umberto Eco

Hi Andrew,
On Mon, May 18, 2009 at 8:07 PM, Andrew Straw <str...@as...> wrote:
> I've been hacking away at adding support for "dropped spines" to MPL
> (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> have come to the conclusion that there is a fundamental issue in the
> code base that the traits package has solved -- many values that depend
> on other values with complicated stuff that happens when one of the
> parent values changes. For example, the location of the text from the
> xaxis depends on the padding value in addition to the xaxis location.
> Now I'm trying to add another element to the mix -- namely an axis spine
> that can change location -- and things are going to spiral into a
> (further) collection of special-cased updates unless there's some
> reworking of the infrastructure.
>
> So, the question is, should I attempt to use traits for this? I guess
> that I won't have the time to re-write the entire code base to use
> traits, but I'd like make a stab a stab at dropped spine support with
> the knowledge that, should I be successful, there's at least a chance we
> would again ship traits with MPL. I imagine we could incrementally move
> more and more to traits if I'm successful, particularly now that we have
> the beginnings of a unit test infrastructure (thanks James!).
>
A couple summers back I wrote the config subpackage for mpl, which is based
on Fernando's traited configobj package TConfig. It hasn't been used or
tested in a while, but the other devs had been pretty good about keeping it
up to date with changes to the regular rcparams. If there is any push to use
Traits in mpl, I would really like to see the config package ressurrected.
To use it, there is a global variable in matplotlib's __init__.py that needs
to be set to True.
Darren

If you switch to traits, will things still build with py2exe? Are there
speed costs? Startup time?
Cheers,
William
On Mon, May 18, 2009 at 8:07 PM, Andrew Straw <str...@as...> wrote:
> I've been hacking away at adding support for "dropped spines" to MPL
> (e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
> have come to the conclusion that there is a fundamental issue in the
> code base that the traits package has solved -- many values that depend
> on other values with complicated stuff that happens when one of the
> parent values changes. For example, the location of the text from the
> xaxis depends on the padding value in addition to the xaxis location.
> Now I'm trying to add another element to the mix -- namely an axis spine
> that can change location -- and things are going to spiral into a
> (further) collection of special-cased updates unless there's some
> reworking of the infrastructure.
>
> So, the question is, should I attempt to use traits for this? I guess
> that I won't have the time to re-write the entire code base to use
> traits, but I'd like make a stab a stab at dropped spine support with
> the knowledge that, should I be successful, there's at least a chance we
> would again ship traits with MPL. I imagine we could incrementally move
> more and more to traits if I'm successful, particularly now that we have
> the beginnings of a unit test infrastructure (thanks James!).
>
> -Andrew
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables
> unlimited royalty-free distribution of the report engine
> for externally facing server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

I've been hacking away at adding support for "dropped spines" to MPL
(e.g. http://jeb.biologists.org/cgi/content/full/211/3/341/FIG7 ) and
have come to the conclusion that there is a fundamental issue in the
code base that the traits package has solved -- many values that depend
on other values with complicated stuff that happens when one of the
parent values changes. For example, the location of the text from the
xaxis depends on the padding value in addition to the xaxis location.
Now I'm trying to add another element to the mix -- namely an axis spine
that can change location -- and things are going to spiral into a
(further) collection of special-cased updates unless there's some
reworking of the infrastructure.
So, the question is, should I attempt to use traits for this? I guess
that I won't have the time to re-write the entire code base to use
traits, but I'd like make a stab a stab at dropped spine support with
the knowledge that, should I be successful, there's at least a chance we
would again ship traits with MPL. I imagine we could incrementally move
more and more to traits if I'm successful, particularly now that we have
the beginnings of a unit test infrastructure (thanks James!).
-Andrew

On Mon, May 18, 2009 at 16:49, M Uhlenhuth <uhl...@ho...> wrote:
> ./CXX/WrapPython.h:42:20: error: Python.h: No such file or directory
is python-dev and all other build dependencies installed?
$ sudo apt-get build-dep matplotlib
should help
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hello all,
I'm running into some problems building from source. 
I'm running 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC
2009 i686 GNU/Linux. I just checked out revision 7118 from svn. When
I run 'python setup.py build', I get the error I've pasted below.
When I do:
maximus@maximus-laptop:/usr/lib/python2.5/site-packages/matplotlib$ sudo python setup.py build > ~/matploterr.txt
This gets sent to the matploterr.txt file:
============================================================================
BUILDING MATPLOTLIB
 matplotlib: 0.98.6svn
 python: 2.5.4 (r254:67916, Apr 4 2009, 17:55:16) [GCC
 4.3.3]
 platform: linux2
REQUIRED DEPENDENCIES
 numpy: 1.2.1
 freetype2: found, but unknown version (no pkg-config)
 * WARNING: Could not find 'freetype2' headers in any
 * of '/usr/local/include', '/usr/include', '.',
 * '/usr/local/include/freetype2',
 * '/usr/include/freetype2', './freetype2'.
OPTIONAL BACKEND DEPENDENCIES
 libpng: found, but unknown version (no pkg-config)
 * Could not find 'libpng' headers in any of
 * '/usr/local/include', '/usr/include', '.'
 Tkinter: no
 * Using default library and include directories for
 * Tcl and Tk because a Tk window failed to open.
 * You may need to define DISPLAY for Tk to work so
 * that setup can determine where your libraries are
 * located. Tkinter present, but header files are not
 * found. You may need to install development
 * packages.
 wxPython: 2.8.9.1
 * WxAgg extension not required for wxPython >= 2.8
 pkg-config: looking for pygtk-2.0 gtk+-2.0
 * Package pygtk-2.0 was not found in the pkg-config
 * search path. Perhaps you should add the directory
 * containing `pygtk-2.0.pc' to the PKG_CONFIG_PATH
 * environment variable No package 'pygtk-2.0' found
 * Package gtk+-2.0 was not found in the pkg-config
 * search path. Perhaps you should add the directory
 * containing `gtk+-2.0.pc' to the PKG_CONFIG_PATH
 * environment variable No package 'gtk+-2.0' found
 * You may need to install 'dev' package(s) to
 * provide header files.
 Gtk+: no
 * Could not find Gtk+ headers in any of
 * '/usr/local/include', '/usr/include', '.'
 Mac OS X native: no
 Qt: no
 Qt4: no
 Cairo: 1.4.12
OPTIONAL DATE/TIMEZONE DEPENDENCIES
 datetime: present, version unknown
 dateutil: 1.4.1
 pytz: matplotlib will provide
adding pytz
OPTIONAL USETEX DEPENDENCIES
 dvipng: no
 ghostscript: 8.64
 latex: 3.141592
 pdftops: 0.10.5
[Edit setup.cfg to suppress the above messages]
============================================================================
pymods ['pylab']
packages
['matplotlib', 'matplotlib.backends', 'matplotlib.projections',
'mpl_toolkits', 'mpl_toolkits.mplot3d', 'mpl_toolkits.axes_grid',
'matplotlib.sphinxext', 'matplotlib.numerix',
'matplotlib.numerix.mlab', 'matplotlib.numerix.ma',
'matplotlib.numerix.linear_algebra', 'matplotlib.numerix.random_array',
'matplotlib.numerix.fft', 'matplotlib.delaunay', 'pytz']
running build
running build_py
creating build
creating build/lib.linux-i686-2.5
copying lib/pylab.py -> build/lib.linux-i686-2.5
creating build/lib.linux-i686-2.5/matplotlib
copying lib/matplotlib/type1font.py -> build/lib.linux-i686-2.5/matplotlib
copying lib/matplotlib/mpl.py -> build/lib.linux-i686-2.5/matplotlib
copying lib/matplotlib/_mathtext_data.py -> build/lib.linux-i686-2.5/matplotlib
.
.
.
.
.
copying lib/pytz/zoneinfo/America/Indiana/Vevay -> build/lib.linux-i686-2.5/pytz/zoneinfo/America/Indiana
creating build/lib.linux-i686-2.5/pytz/zoneinfo/America/North_Dakota
copying lib/pytz/zoneinfo/America/North_Dakota/New_Salem -> build/lib.linux-i686-2.5/pytz/zoneinfo/America/North_Dakota
copying lib/pytz/zoneinfo/America/North_Dakota/Center -> build/lib.linux-i686-2.5/pytz/zoneinfo/America/North_Dakota
running build_ext
building 'matplotlib.ft2font' extension
creating build/temp.linux-i686-2.5
creating build/temp.linux-i686-2.5/src
creating build/temp.linux-i686-2.5/CXX
gcc
-pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DPY_ARRAYAUNIQUE_SYMBOL=MPL_ARRAY_API
-I/usr/lib/python2.5/site-packages/numpy/core/include
-I/usr/local/include -I/usr/include -I.
-I/usr/lib/python2.5/site-packages/numpy/core/include/freetype2
-I/usr/local/include/freetype2 -I/usr/include/freetype2 -I./freetype2
-I/usr/include/python2.5 -c src/ft2font.cpp -o
build/temp.linux-i686-2.5/src/ft2font.o
And this gets output in th terminal:
cc1plus: warning: command line option "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++
In file included from ./CXX/Extensions.hxx:48,
 from src/ft2font.h:4,
 from src/ft2font.cpp:1:
./CXX/WrapPython.h:42:20: error: Python.h: No such file or directory
In file included from ./CXX/Extensions.hxx:50,
 from src/ft2font.h:4,
 from src/ft2font.cpp:1:
./CXX/Config.hxx:112:2: error: #error not defined PY_MAJOR_VERSION
In file included from /usr/include/c++/4.3/ext/hash_map:64,
 from ./CXX/Extensions.hxx:68,
 from src/ft2font.h:4,
 from src/ft2font.cpp:1:
/usr/include/c++/4.3/backward/backward_warning.h:33:2:
warning: #warning This file includes at least one deprecated or
antiquated header which may be removed without further notice at a
future date. Please use a non-deprecated interface with equivalent
functionality instead. For a listing of replacement headers and
interfaces, consult the file backward_warning.h. To disable this
warning use -Wno-deprecated.
In file included from src/ft2font.cpp:1:
src/ft2font.h:13:22: error: ft2build.h: No such file or directory
src/ft2font.h:14:10: error: #include expects "FILENAME" or <FILENAME>
src/ft2font.h:15:10: error: #include expects "FILENAME" or <FILENAME>
src/ft2font.h:16:10: error: #include expects "FILENAME" or <FILENAME>
src/ft2font.h:17:10: error: #include expects "FILENAME" or <FILENAME>
src/ft2font.h:18:10: error: #include expects "FILENAME" or <FILENAME>
In file included from /usr/lib/python2.5/site-packages/numpy/core/include/numpy/arrayobject.h:14,
 from src/ft2font.cpp:5:
/usr/lib/python2.5/site-packages/numpy/core/include/numpy/ndarrayobject.h:114:2:
error: #error Must use Python with unicode enabled.
In file included from ./CXX/Exception.hxx:44,
 from ./CXX/Objects.hxx:44,
 from ./CXX/Extensions.hxx:51,
 from src/ft2font.h:4,
 from src/ft2font.cpp:1:
./CXX/IndirectPythonInterface.hxx:50: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:51: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:52: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:53: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:55: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:56: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:57: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:58: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:59: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:60: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:61: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:62: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:63: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:64: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:65: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:66: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:67: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:68: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:69: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:70: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:71: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:72: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:73: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:74: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:75: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:76: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:81: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:93: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:95: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:96: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:101: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:102: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:102: error: ‘o’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:104: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:105: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:105: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:107: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:108: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:108: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:110: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:111: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:111: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:113: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:114: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:114: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:116: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:117: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:117: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:119: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:120: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:120: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:122: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:123: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:123: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:125: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:126: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:126: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:128: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:129: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:129: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:131: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:132: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:132: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:134: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:135: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:135: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:137: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:138: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:138: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:140: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:141: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:141: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:143: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:144: error: redefinition of ‘bool Py::_List_Check’
./CXX/IndirectPythonInterface.hxx:102: error: ‘bool Py::_List_Check’ previously defined here
./CXX/IndirectPythonInterface.hxx:144: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:144: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:146: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:147: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:147: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:149: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:150: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:150: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:152: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:153: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:153: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:155: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:156: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:156: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:158: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:159: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:159: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:161: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:162: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:162: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:164: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:165: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:165: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:167: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:168: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:168: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:170: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:171: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:171: error: ‘v’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:173: error: expected constructor, destructor, or type conversion before ‘*’ token
./CXX/IndirectPythonInterface.hxx:174: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:174: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:192: error: variable or field ‘_XINCREF’ declared void
./CXX/IndirectPythonInterface.hxx:192: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:192: error: ‘op’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:193: error: variable or field ‘_XDECREF’ declared void
./CXX/IndirectPythonInterface.hxx:193: error: ‘PyObject’ was not declared in this scope
./CXX/IndirectPythonInterface.hxx:193: error: ‘op’ was not declared in this scope
In file included from ./CXX/Objects.hxx:44,
 from ./CXX/Extensions.hxx:51,
 from src/ft2font.h:4,
 from src/ft2font.cpp:1:
./CXX/Exception.hxx:70: error: expected `)' before ‘*’ token
./CXX/Exception.hxx:75: error: expected `)' before ‘*’ token
./CXX/Exception.hxx: In constructor ‘Py::Exception::Exception(const std::string&)’:
./CXX/Exception.hxx:67: error: ‘_Exc_RuntimeError’ is not a member of ‘Py’
./CXX/Exception.hxx:67: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In member function ‘void Py::Exception::clear()’:
./CXX/Exception.hxx:80: error: ‘PyErr_Clear’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::TypeError::TypeError(const std::string&)’:
./CXX/Exception.hxx:122: error: ‘_Exc_TypeError’ is not a member of ‘Py’
./CXX/Exception.hxx:122: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::IndexError::IndexError(const std::string&)’:
./CXX/Exception.hxx:132: error: ‘_Exc_IndexError’ is not a member of ‘Py’
./CXX/Exception.hxx:132: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::AttributeError::AttributeError(const std::string&)’:
./CXX/Exception.hxx:142: error: ‘_Exc_AttributeError’ is not a member of ‘Py’
./CXX/Exception.hxx:142: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::NameError::NameError(const std::string&)’:
./CXX/Exception.hxx:152: error: ‘_Exc_NameError’ is not a member of ‘Py’
./CXX/Exception.hxx:152: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::RuntimeError::RuntimeError(const std::string&)’:
./CXX/Exception.hxx:162: error: ‘_Exc_RuntimeError’ is not a member of ‘Py’
./CXX/Exception.hxx:162: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::SystemError::SystemError(const std::string&)’:
./CXX/Exception.hxx:172: error: ‘_Exc_SystemError’ is not a member of ‘Py’
./CXX/Exception.hxx:172: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::KeyError::KeyError(const std::string&)’:
./CXX/Exception.hxx:182: error: ‘_Exc_KeyError’ is not a member of ‘Py’
./CXX/Exception.hxx:182: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::ValueError::ValueError(const std::string&)’:
./CXX/Exception.hxx:193: error: ‘_Exc_ValueError’ is not a member of ‘Py’
./CXX/Exception.hxx:193: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::OverflowError::OverflowError(const std::string&)’:
./CXX/Exception.hxx:203: error: ‘_Exc_OverflowError’ is not a member of ‘Py’
./CXX/Exception.hxx:203: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::ZeroDivisionError::ZeroDivisionError(const std::string&)’:
./CXX/Exception.hxx:213: error: ‘_Exc_ZeroDivisionError’ is not a member of ‘Py’
./CXX/Exception.hxx:213: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::FloatingPointError::FloatingPointError(const std::string&)’:
./CXX/Exception.hxx:223: error: ‘_Exc_FloatingPointError’ is not a member of ‘Py’
./CXX/Exception.hxx:223: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::MemoryError::MemoryError(const std::string&)’:
./CXX/Exception.hxx:233: error: ‘_Exc_MemoryError’ is not a member of ‘Py’
./CXX/Exception.hxx:233: error: ‘PyErr_SetString’ was not declared in this scope
./CXX/Exception.hxx: In constructor ‘Py::SystemExit::SystemExit(const std::string&)’:
./CXX/Exception.hxx:243: error: ‘_Exc_SystemExit’ is not a member of ‘Py’
./CXX/Exception.hxx:243: error: ‘PyErr_SetString’ was not declared in this scope
In file included from ./CXX/Extensions.hxx:51,
 from src/ft2font.h:4,
 from src/ft2font.cpp:1:
./CXX/Objects.hxx: At global scope:
./CXX/Objects.hxx:66: error: expected initializer before ‘*’ token
./CXX/Objects.hxx:74: error: expected initializer before ‘*’ token
./CXX/Objects.hxx:150: error: ISO C++ forbids declaration of ‘PyObject’ with no type
./CXX/Objects.hxx:150: error: expected ‘;’ before ‘*’ token
./CXX/Objects.hxx:154: error: ‘PyObject’ has not been declared
./CXX/Objects.hxx:175: error: expected `)' before ‘*’ token
src/ft2font.cpp:1936: error: expected `}' at end of input
./CXX/Objects.hxx: In member function ‘void Py::Object::set(int*, bool)’:
./CXX/Objects.hxx:157: error: ‘p’ was not declared in this scope
./CXX/Objects.hxx:160: error: ‘_XINCREF’ is not a member of ‘Py’
./CXX/Objects.hxx: In member function ‘void Py::Object::release()’:
./CXX/Objects.hxx:167: error: ‘_XDECREF’ is not a member of ‘Py’
./CXX/Objects.hxx:167: error: ‘p’ was not declared in this scope
./CXX/Objects.hxx: At global scope:
./CXX/Objects.hxx:169: error: expected unqualified-id at end of input
./CXX/Objects.hxx:169: error: expected `}' at end of input
error: command 'gcc' failed with exit status 1
Thanks!
-Max

==========================
SciPy 2009 Call for Papers
==========================
SciPy 2009, the 8th Python in Science conference, will be held
from August 18-23, 2009 at Caltech in Pasadena, CA, USA.
Each year SciPy attracts leading figures in research and scientific
software development with Python from a wide range of scientific and
engineering disciplines. The focus of the conference is both on scientific
libraries and tools developed with Python and on scientific or engineering
achievements using Python.
We welcome contributions from the industry as well as the academic world.
Indeed, industrial research and development as well academic research
face the challenge of mastering IT tools for exploration, modeling and
analysis.
We look forward to hearing your recent breakthroughs using Python!
Submission of Papers
====================
The program features tutorials, contributed papers, lightning talks, and
bird-of-a-feather sessions. We are soliciting talks and accompanying
papers (either formal academic or magazine-style articles) that discuss
topics which center around scientific computing using Python. These
include applications, teaching, future development directions, and
research. A collection of peer-reviewed articles will be published as
part of the proceedings.
Proposals for talks are submitted as extended abstracts. There are two
categories of talks:
 Paper presentations
 These talks are 35 minutes in duration (including questions). A one page
 abstract of no less than 500 words (excluding figures and references)
 should give an outline of the final paper. Proceeding papers are due two
 weeks after the conference, and may be in a formal academic style, or in
 a more relaxed magazine-style format.
 Rapid presentations
 These talks are 10 minutes in duration. An abstract of between
 300 and 700 words should describe the topic and motivate its
 relevance to scientific computing.
In addition, there will be an open session for lightning talks during which
any attendee willing to do so is invited to do a couple-of-minutes-long
presentation.
If you wish to present a talk at the conference, please create an account
on the website (http://conference.scipy.org). You may then submit an abstract
by logging in, clicking on your profile and following the "Submit an
abstract" link.
Submission Guidelines
---------------------
* Submissions should be uploaded via the online form.
* Submissions whose main purpose is to promote a commercial product or
 service will be refused.
* All accepted proposals must be presented at the SciPy conference by
 at least one author.
* Authors of an accepted proposal can provide a final paper for
 publication in the conference proceedings. Final papers are limited
 to 7 pages, including diagrams, figures, references, and appendices.
 The papers will be reviewed to help ensure the high-quality of the
 proceedings.
For further information, please visit the conference homepage:
http://conference.scipy.org.
Important Dates
===============
* Friday, June 26: Abstracts Due
* Saturday, July 4: Announce accepted talks, post schedule
* Friday, July 10: Early Registration ends
* Tuesday-Wednesday, August 18-19: Tutorials
* Thursday-Friday, August 20-21: Conference
* Saturday-Sunday, August 22-23: Sprints
* Friday, September 4: Papers for proceedings due
Tutorials
=========
Two days of tutorials to the scientific Python tools will precede the
conference. There will be two tracks: one for introduction of the basic
tools to beginners and one for more advanced tools. Tutorials will be
announced later.
Birds of a Feather Sessions
===========================
If you wish to organize a birds-of-a-feather session to discuss some
specific area of scientific development with Python, please contact the
organizing committee.
Executive Committee
===================
* Jarrod Millman, UC Berkeley, USA (Conference Chair)
* Gaël Varoquaux, INRIA Saclay, France (Program Co-Chair)
* Stéfan van der Walt, University of Stellenbosch, South Africa
(Program Co-Chair)
* Fernando Pérez, UC Berkeley, USA (Tutorial Chair)

On Wed, May 13, 2009 at 3:07 PM, Eric Firing <ef...@ha...> wrote:
>
> Please check and try out revision 7100. For example, with ipython -pylab:
>
>
> x = np.arange(1000000, dtype=float) * 0.2
> y = np.sin(x)
> plot(x,y)
> xlim(10,20)
>
> Then play around with panning and zooming.
>
> To see what the behavior is like without the changes, just reverse the
> sign of x, since at present only monotonically increasing x is supported:
>
> plot(-x, y)
> xlim(-20,-10)
>
> Notice that in the latter case, panning and zooming is jerky.
>
Works great for me here, nice work.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

I just downloaded wxversion.py from the wxPython trunk and everything 
seems to working fine. Thanks for your help!
-T
On May 14, 2009, at 1:27 PM, Eric Firing wrote:
> Tony Yu wrote:
>> I hope you don't mind if I bump this.
>> I'm curious if Eric, or any others from the following thread had a 
>> comment on this issue:
>> http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
>> I don't mind upgrading if that's what's required, but I was just 
>> wondering if this issue was an intended result of the patch.
>
> Tony,
>
> No, it certainly wasn't.
>
> As for upgrading, it looks to me like you don't need to upgrade 
> wxpython, just wxversion, which is a single independent file.
>
> I don't know whether wxversion is always packaged with a wxpython 
> itself, or whether it is distributed separately.
>
> I don't see any decent workaround. We can't just catch VersionError 
> instead of AlreadyImportedError because that would defeat the 
> purpose. It looks to me like upgrading wxversion is the only option, 
> unless someone with wx expertise wants to plunge in and figure out a 
> better solution. The only other thing I can think of would be for 
> mpl to include its own copy of wxversion. I would prefer not to 
> clutter mpl that way--it would be just one more obscure thing to 
> maintain.
>
> Eric
>
>> Best,
>> -Tony
>> On May 8, 2009, at 8:46 PM, Tony S Yu wrote:
>>> I'm running into the following error with the wx backend
>>>
>>>>>>> import wx
>>>>>>> import matplotlib.backends.backend_wxagg
>>>> Traceback (most recent call last):
>>>> File "<stdin>", line 1, in <module>
>>>> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
>>>> matplotlib/backends/backend_wxagg.py", line 23, in <module>
>>>> import backend_wx # already uses 
>>>> wxversion.ensureMinimal('2.8')
>>>> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
>>>> matplotlib/backends/backend_wx.py", line 120, in <module>
>>>> except wxversion.AlreadyImportedError:
>>>> AttributeError: 'module' object has no attribute 
>>>> 'AlreadyImportedError'
>>>
>>> This problem seems to be related to additions made here:
>>> http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
>>>
>>> The problem is that my version of wxversion raises 'VersionError' 
>>> instead of 'AlreadyImportedError'.
>>>
>>> I'm running wxPython 2.8.4.0 while people in the above thread seem 
>>> to be using at least 2.8.7.1. Do I need to upgrade, or is this a 
>>> bug?
>>>
>>> Thanks,
>>> -Tony
>>>
>>> ------------------------------------------------------------------------------
>>> The NEW KODAK i700 Series Scanners deliver under ANY 
>>> circumstances! Your
>>> production scanning environment may not be a perfect world - but 
>>> thanks to
>>> Kodak, there's a perfect scanner to get the job done! With the NEW 
>>> KODAK i700
>>> Series Scanner you'll get full speed at 300 dpi even with all image
>>> processing features enabled. http://p.sf.net/sfu/kodak-com
>>> _______________________________________________
>>> Matplotlib-devel mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
~~~~
Tony S Yu
PhD Candidate
Hatsopoulos Microfluids Laboratory
email: ts...@gm...
office: 617.324.0128

Tony Yu wrote:
> I hope you don't mind if I bump this.
> 
> I'm curious if Eric, or any others from the following thread had a 
> comment on this issue:
> http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
> 
> I don't mind upgrading if that's what's required, but I was just 
> wondering if this issue was an intended result of the patch.
Tony,
No, it certainly wasn't.
As for upgrading, it looks to me like you don't need to upgrade 
wxpython, just wxversion, which is a single independent file.
I don't know whether wxversion is always packaged with a wxpython 
itself, or whether it is distributed separately.
I don't see any decent workaround. We can't just catch VersionError 
instead of AlreadyImportedError because that would defeat the purpose. 
It looks to me like upgrading wxversion is the only option, unless 
someone with wx expertise wants to plunge in and figure out a better 
solution. The only other thing I can think of would be for mpl to 
include its own copy of wxversion. I would prefer not to clutter mpl 
that way--it would be just one more obscure thing to maintain.
Eric
> 
> Best,
> -Tony
> 
> 
> On May 8, 2009, at 8:46 PM, Tony S Yu wrote:
> 
>> I'm running into the following error with the wx backend
>>
>>>>>> import wx
>>>>>> import matplotlib.backends.backend_wxagg
>>> Traceback (most recent call last):
>>> File "<stdin>", line 1, in <module>
>>> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
>>> matplotlib/backends/backend_wxagg.py", line 23, in <module>
>>> import backend_wx # already uses wxversion.ensureMinimal('2.8')
>>> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
>>> matplotlib/backends/backend_wx.py", line 120, in <module>
>>> except wxversion.AlreadyImportedError:
>>> AttributeError: 'module' object has no attribute 
>>> 'AlreadyImportedError'
>>
>> This problem seems to be related to additions made here:
>> http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
>>
>> The problem is that my version of wxversion raises 'VersionError' 
>> instead of 'AlreadyImportedError'.
>>
>> I'm running wxPython 2.8.4.0 while people in the above thread seem to 
>> be using at least 2.8.7.1. Do I need to upgrade, or is this a bug?
>>
>> Thanks,
>> -Tony
>>
>> ------------------------------------------------------------------------------
>> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
>> production scanning environment may not be a perfect world - but thanks to
>> Kodak, there's a perfect scanner to get the job done! With the NEW 
>> KODAK i700
>> Series Scanner you'll get full speed at 300 dpi even with all image
>> processing features enabled. http://p.sf.net/sfu/kodak-com
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
> 
> 
> 

I hope you don't mind if I bump this.
I'm curious if Eric, or any others from the following thread had a 
comment on this issue:
http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
I don't mind upgrading if that's what's required, but I was just 
wondering if this issue was an intended result of the patch.
Best,
-Tony
On May 8, 2009, at 8:46 PM, Tony S Yu wrote:
> I'm running into the following error with the wx backend
>
>>>>> import wx
>>>>> import matplotlib.backends.backend_wxagg
>> Traceback (most recent call last):
>> File "<stdin>", line 1, in <module>
>> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
>> matplotlib/backends/backend_wxagg.py", line 23, in <module>
>> import backend_wx # already uses wxversion.ensureMinimal('2.8')
>> File "/Users/Tony/python/matplotlib/trunk/matplotlib/lib/
>> matplotlib/backends/backend_wx.py", line 120, in <module>
>> except wxversion.AlreadyImportedError:
>> AttributeError: 'module' object has no attribute
>> 'AlreadyImportedError'
>
> This problem seems to be related to additions made here:
> http://www.nabble.com/Selecting-WX2.8-in-examples-td22380586.html
>
> The problem is that my version of wxversion raises 'VersionError'
> instead of 'AlreadyImportedError'.
>
> I'm running wxPython 2.8.4.0 while people in the above thread seem to
> be using at least 2.8.7.1. Do I need to upgrade, or is this a bug?
>
> Thanks,
> -Tony
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! 
> Your
> production scanning environment may not be a perfect world - but 
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW 
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Please check and try out revision 7100. For example, with ipython -pylab:
x = np.arange(1000000, dtype=float) * 0.2
y = np.sin(x)
plot(x,y)
xlim(10,20)
Then play around with panning and zooming.
To see what the behavior is like without the changes, just reverse the 
sign of x, since at present only monotonically increasing x is supported:
plot(-x, y)
xlim(-20,-10)
Notice that in the latter case, panning and zooming is jerky.
Thanks.
Eric

On Mon, May 11, 2009 at 2:56 PM, Christopher Barker
<Chr...@no...>wrote:
> Jouni K. Seppänen wrote:
> > http://en.wikipedia.org/wiki/ClearType
>
> Reading that web page, I'm not convinced MS made the right decision here
> -- on my monitor (which is a ViewSonic LCD, probably pretty standard),
> I'm not sure the ClearType examples really look any better, and they
> certainly could look worse on other displays.
>
That could be because you have an unusual RGB subpixel layout, or because
the implementation of subpixel rendering on your system yields color
fringes. I don't have these problems on my ubuntu or gentoo systems, and
text looks much better on my LCDs when I have subpixel rendering enabled. I
think the users settings should be respected, if possible.
Darren

Freddie Witherden wrote:
> I -- personally -- am not a fan of Microsoft's implementation of 
> subpixel rendering either. I feel that it applies far too heavy 
> hinting to glyphs in order to force them into the pixel grid.
actually, that's a separate issue. the one in that wiki page is taking 
advantage of the fact that a single rgb "pixel" is really three pixels, 
one of each color, and, if you now how those are arranged (and 
apparently they are mostly arranged the same on LCD monitors), you can 
turn on more or less of a color to get a third of the pixel.
> studies have shown that people like what they're used to.
yup. Though I think that MPL is not rendering big blocks of text, the 
there is less "used to" in this case.
> Safari 3 was released for Windows Apple ported their own font 
> rendering engine -- which uses almost no hinting -- provoking many 
> complains from Windows users, who had gotten used to their well hinted 
> glyphs.)
And this is the trick that MS uses to shift glyphs right or left to line 
vertical lines up with the pixel grid. This is nice commentary on a 
bunch of this:
http://www.antigrain.com/research/font_rasterization/
I wonder how the MS tricks do for math -- I'd expect kind of a mess.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Hi,
On 11 May 2009, at 19:56, Christopher Barker wrote:
> Jouni K. Seppänen wrote:
>> http://en.wikipedia.org/wiki/ClearType
>
> Reading that web page, I'm not convinced MS made the right decision 
> here
> -- on my monitor (which is a ViewSonic LCD, probably pretty 
> standard), 
> I'm not sure the ClearType examples really look any better, and they
> certainly could look worse on other displays.
I -- personally -- am not a fan of Microsoft's implementation of 
subpixel rendering either. I feel that it applies far too heavy 
hinting to glyphs in order to force them into the pixel grid. However, 
studies have shown that people like what they're used to. (E.g., when 
Safari 3 was released for Windows Apple ported their own font 
rendering engine -- which uses almost no hinting -- provoking many 
complains from Windows users, who had gotten used to their well hinted 
glyphs.)
> I say just turn it off everywhere, it's the safer bet.
If adding a configuration option is not viable (complexity of doing 
so, potentially confusion to users, not enough scope, &c) then yes -- 
disabling it is the safest option. But for those who do have it 
enabled for their desktop it would be good if Matplotlib was able to 
respect that for onscreen rendering.
Regards, Freddie.

Hello,
 Does anyone know how I could plot contours on a chart like this? 
thanks,
Robert
-- 
View this message in context: http://www.nabble.com/Polar-Plot-tp22590831p23490797.html
Sent from the matplotlib - devel mailing list archive at Nabble.com.

Jouni K. Seppänen wrote:
> http://en.wikipedia.org/wiki/ClearType
Reading that web page, I'm not convinced MS made the right decision here 
-- on my monitor (which is a ViewSonic LCD, probably pretty standard), 
I'm not sure the ClearType examples really look any better, and they 
certainly could look worse on other displays.
Also from that page:
"""
Additionally, when images are prepared to be display-independent (that 
is, when they are prepared for distribution, and not just for display on 
the computer with which they were prepared), ClearType should be turned 
off if rendered text is part of the image. For example, screenshots 
should always be prepared with ClearType turned off. Image-editing 
programs such as Adobe Photoshop or Corel Paint Shop Pro bypass 
ClearType when rendering text directly, for precisely this reason.
"""
I say just turn it off everywhere, it's the safer bet.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

That plan makes sense to me. 
The argument I was trying to make was against subpixel rendering as a 
property of each Text object in matplotlib -- but later realised that's 
not really applicable to what you're doing with the external math tool 
anyway.
Cheers,
Mike
Freddie Witherden wrote:
> Hi all,
>
> On 11 May 2009, at 12:43, Michael Droettboom wrote:
> 
>> I'm with Eric on this -- let's try to do the right thing without
>> requiring any user intervention. I actually can't think of a use case
>> that would require a subpixel argument on text... am I missing 
>> something?
>> 
>
> Cairo has an image backend, which is usually used for both on-screen 
> rendering and which also supports saving to a file. When displaying on- 
> screen the default is most probably fine -- Cairo gets its subpixel 
> rendering settings from the OS (fontconfig on Linux) so all is well.
>
> However, when saving to a file, depending on its intended use one may 
> either want to enable/disable subpixel antialiasing/rendering. If it 
> is intended for print you probably want to disable it, however, for 
> web graphics subpixel rendering is extremely common.
>
> Furthermore Cairo also has provisions for subpixel antialiasing for 
> line art. (So the same techniques which are applied to text are also 
> applied to polygons, curves &c.) While none of the backends currently 
> make use of it, it is quite likely that in the future the image 
> backend will support it. Therefore a general subpixel antialiasing 
> setting might be a better bet.
>
> I would therefore suggest having two options: one for when printing 
> and another for displaying on screen. The default for printing/saving 
> should probably be off, while the displaying should be got from the 
> system.
>
> Regards, Freddie.
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> 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 all,
On 11 May 2009, at 12:43, Michael Droettboom wrote:
> I'm with Eric on this -- let's try to do the right thing without
> requiring any user intervention. I actually can't think of a use case
> that would require a subpixel argument on text... am I missing 
> something?
Cairo has an image backend, which is usually used for both on-screen 
rendering and which also supports saving to a file. When displaying on- 
screen the default is most probably fine -- Cairo gets its subpixel 
rendering settings from the OS (fontconfig on Linux) so all is well.
However, when saving to a file, depending on its intended use one may 
either want to enable/disable subpixel antialiasing/rendering. If it 
is intended for print you probably want to disable it, however, for 
web graphics subpixel rendering is extremely common.
Furthermore Cairo also has provisions for subpixel antialiasing for 
line art. (So the same techniques which are applied to text are also 
applied to polygons, curves &c.) While none of the backends currently 
make use of it, it is quite likely that in the future the image 
backend will support it. Therefore a general subpixel antialiasing 
setting might be a better bet.
I would therefore suggest having two options: one for when printing 
and another for displaying on screen. The default for printing/saving 
should probably be off, while the displaying should be got from the 
system.
Regards, Freddie.

Maybe people understand different things by the name "subpixel
rendering". In Agg, subpixel rendering means antialiasing like this:
http://www.antigrain.com/screenshots/agg1_01.jpg
In Cairo, I'm guessing (since the OP mentioned Microsoft's ClearType)
that "subpixel rendering" means utilizing the RGB subpixels on LCD
monitors:
http://en.wikipedia.org/wiki/ClearType
A potential problem is that different people have different displays; at
least when configuring CoolType in Adobe Reader, you have a range of
options to select from. I imagine that Cairo has a similar global
setting, and in my opinion Matplotlib should simply respect that setting
when rendering on screen. File output is more complicated: what if the
file is viewed on a different kind of display than it was generated on?
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

I'm with Eric on this -- let's try to do the right thing without 
requiring any user intervention. I actually can't think of a use case 
that would require a subpixel argument on text... am I missing something?
Mike
Eric Firing wrote:
> John Hunter wrote:
> 
>> On Sat, May 9, 2009 at 9:32 AM, Freddie Witherden <fr...@wi...> wrote:
>> 
>>> Hi all,
>>>
>>> As some of you probably know I am working on the GSoC project to
>>> externalise the Mathtex engine from Matplotlib. Today I have been
>>> toying around with the renderer using various backends.
>>>
>>> One of the interesting things that I discovered was that the Cairo
>>> backend was making use of subpixel rendering. (Or 'ClearType' as
>>> Microsoft call it.) This is not surprising -- by default Cairo will
>>> respect a users fontconfig settings when rendering text. Since I have
>>> subpixel rendering enabled all text rendered by Cairo is subpixel
>>> rendered.
>>>
>>> While this is fantastic for on screen text -- being significantly more
>>> pleasing to look at that the text produced by the AGG backend -- it is
>>> unsuitable for print. Now it is not too difficult to disable this,
>>> Cairo has an API call: cairo_font_options_set_antialias to deal with
>>> this.
>>>
>>> While I could write a quick patch to always disable subpixel rendering
>>> it would be something off a loss to those who either view their graphs
>>> onscreen or export them for the web -- where using subpixel rendering
>>> is now surprisingly common.
>>>
>>> Is it worth looking into adding subpixel rendering as a configuration
>>> option?
>>> 
>> The matplotlib.lines.Line2D objects has an antialiased property -- we
>> could add the same property to matplotlib.text.Text to turn on/off
>> subpixel rendering (which could also be supported as an rc param)
>> 
>
> I haven't poked around, so this may be a stupid question, but: for 
> cairo, can subpixel rendering simply be left on for screen display and 
> automatically turned off when writing to a file via savefig? If this 
> can be done, it seems like a better solution than requiring to the user 
> to turn the parameter on and off manually, depending on whether show() 
> or savefig() is being called.
>
> Eric
>
> 
>> JDH
>> 
>
> ------------------------------------------------------------------------------
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
> production scanning environment may not be a perfect world - but thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image 
> processing features enabled. http://p.sf.net/sfu/kodak-com
> _______________________________________________
> 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

John Hunter wrote:
<snip>
> The matplotlib.lines.Line2D objects has an antialiased property -- we
> could add the same property to matplotlib.text.Text to turn on/off
> subpixel rendering (which could also be supported as an rc param)
> 
> JDH
What are the supported combinations of subpixel rendering and 
antialiasing? Are they mutually exclusive? If Cairo supports both at the 
same time, I don't think it would be a good idea to enable subpixel 
rendering using a property called "antialiased".
Gary R.

Hello,
It has always bugged me that it's not easy to display minor ticks in matplotlib,
and there is no easy way to make minor ticks autoscale the same way major ticks 
do.
I just added a patch to tracker that (I hope!) fixes these two problems. 
https://sourceforge.net/tracker/?func=detail&aid=2789713&
group_id=80706&atid=560722
It adds a new locator class, AutoMinorLocator, that can be used to dynamically
find minor tick positions based on major tick positions. It also adds a new
function to pyplot, minorticks(), that can be used to toggle the minorticks on
and off. Adding autoscaling minor ticks reduces performance, but not excessively
(on my Intel centrino duo laptop). They should probably be off by default though.
Any comments are welcome,
Neil