Ondrej Certik wrote: > On Jan 4, 2008 7:41 PM, Michael Droettboom <[EMAIL PROTECTED]> wrote: >> Ondrej Certik wrote: >>> * freetype (this could be rewritten using ctypes) >> I see that pyglet already has a freetype wrapper using ctypes -- it >> would be interesting to see if that could be used as a starting point. >> That could be used as a starting point. (Of course, ctypes is an >> external dependency before Python-2.5, which adds a dependency to >> matplotlib). > > That is correct. I forgot about that. We do support python2.4 and it's > true that in order > for plotting to work, you need to install python-ctypes. > But python2.4 will hopefully get old soon, in favor of python2.5.
Agreed. I know there are still some matplotlib users on python2.3, but they'll have to move on eventually... ;) >> I generally don't like ctypes-based wrappers since changes in the >> dependency can mean segfaults at runtime. I'm having a problem getting >> pyglet to work on my particular version of OpenGL, for instance. But >> perhaps freetype is stable enough for that not to be a problem. > > Could you please report it to http://groups.google.com/group/pyglet-users ? Sorry -- I should have mentioned I already did. >>> * Agg (this could be optional) >> On the transforms branch, Agg is used for bezier curve realisation, >> whether the Agg renderer is being used or not. This is used for things >> like hit-testing and range-setting of path collections etc. This was >> not fast enough in my earlier numpy-based implementation, since to take >> advantage of numpy, you generally have to allocate lots of memory to >> store the results in. In this particular case, each value can be >> immediately thrown away, so all that extra work was unnecessary. > > So it's needed for path collections - what is that? A collection of a large number of paths (or polygons) that need to be rendered quickly. > When I want to do > regular plots, > like plotting some set of points, is that needed too? If not, it > should be optional imho. That's actually a tough one. On the transforms branch, by the time it hits the rendering level, everything is a polycurve path. Determining if something contains curves or not (which in the current implementation would require running through the entire path, which may be quite large) would probably be too slow. >>> Compiling really sucks. >> Agreed. But there is a spectrum of suckage here. It also sucks to be >> unable to check that a call to some library that you don't provide >> (freetype) will succeed. > > That sucks too. But I think there are mechanisms to check the exact version > of the library, aren't there? There are. But the multiple versions of the library must be individually tested to have a hope of working -- whereas with the compiled model, sometimes the changes between library versions will be seamless, other times the compile will fail, both of which are preferable to segfaulting at runtime (which admittedly is still possible even when compiling.) >>>>> Another cool stuff in matplotlib is the pure python latex renderer >>>>> (/matplotlib-0.91.1/lib/matplotlib/mathtext.py). See our issue for >>>>> more info: >>>> Yes, the mathtext support in matplotlib is very nice, and Michael >>>> deserves the credit for taking from a package that >>>> works but has warts, to an extremely nice math layout engine using the >>>> Knuth algorithms. I'm sure others would like to use it without having >>>> to pull in all of matplotlib. With a ctypes freetype wrapper, it >>>> should be possible to build a free-standing mathtext. >>> And this is really cool. I would like to have that. :) >>> >>> We'll try to help with that one. >> Great! I'll start by looking at pyglet's freetype wrapper and see how >> far I get. > > Awesome. Please ask on the list above, as I said, Alex is quite guru, so he > will answer any technical questions. Thanks, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
