Ken McIvor wrote:
This means someone needs to figure out how to get TkInter talking to a python
buffer object or a numpy array.I think PIL's ImageTk module would do the trick for converting RGBA -> PIL Image -> Tk Bitmap/PhotoImage.
That's what I was thinking, too. I don't think there's a way to do this in a raw Tkinter. But is PIL something we plan to depend on?
Cheers,
Mike
I don't know, although I'm warming to the idea myself. If we don't want the Tk backend to depend on PIL, we could create a string containing an X11 bitmap of the renderer's RGB array and use it to construct or update a Tkinter.BitmapImage.
Ken
On Jul 20, 2007, at 6:26 AM, Michael Droettboom wrote:
Ken McIvor wrote:
I think PIL's ImageTk module would do the trick for converting RGBA ->
PIL Image -> Tk Bitmap/PhotoImage.That's what I was thinking, too. I don't think there's a way to do this
in a raw Tkinter. But is PIL something we plan to depend on?
Ken McIvor wrote:
Ken McIvor wrote:
I think PIL's ImageTk module would do the trick for converting RGBA ->
PIL Image -> Tk Bitmap/PhotoImage.That's what I was thinking, too. I don't think there's a way to do this
in a raw Tkinter. But is PIL something we plan to depend on?I don't know, although I'm warming to the idea myself. If we don't want the Tk backend to depend on PIL, we could create a string containing an X11 bitmap of the renderer's RGB array and use it to construct or update a Tkinter.BitmapImage.
Tkinter.BitmapImage s are one-bit -- it would have to be a Tkinter.PhotoImage. The options for file formats are GIF and PGM/PPM. PPM is the only of those that supports TrueColor. It would have to be able to be generated efficiently enough from pure Python (seems possible, but I haven't tried yet).
My bigger concern, though, is that there seems to be no way to update just a subregion of the PhotoImage from pure Python. I see that the C code in _tkagg.cpp can do this. Does that actually get used or is it always a full image?
Cheers,
Mike
On Jul 20, 2007, at 6:26 AM, Michael Droettboom wrote:
Yes we use it and this is a very useful feature, one we can hopefully
expand on for more efficient rendering. Eg, FigureCanvasTkAgg.blit
uses it.
Truth be told, the tk GUI code has never caused us any real headaches
from a compilation perspective, so we *could* live with it, but don't
let me dissuade you from finding a creative python solution.
JDH
On 7/20/07, Michael Droettboom <mdroe@...31...> wrote:
er concern, though, is that there seems to be no way to update
just a subregion of the PhotoImage from pure Python. I see that the C
code in _tkagg.cpp can do this. Does that actually get used or is it
always a full image?
Ken McIvor wrote:
But is PIL something we plan to depend on?
I don't know, although I'm warming to the idea myself.
Is PIL's DrawAgg numpy-aware? I suspect not. That could make difference when drawing lines with LOTS of points, for instance. I suppose we could contribute the array-aware code, but I don't know if it would be accepted.
-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
Chris.Barker@...236...
Darren Dale wrote:
Is there much demand for BSD-compliant svg, pdf, and ps backends?
Is the demand any different than for any other back end?
I wonder about the demand for BSD MPL over all. I know we want people to be able to use MPL in proprietary apps, but the LGPL allows that.
How important is it that people can actually improve MPL without contributing those improvements back? Isn't that what BSD allows that LGPL doesn't?
By the way, isn't wxPython modified LGPL? We have a wx back-end.
-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
Chris.Barker@...236...
Where can I find that? I did some googling, and no luck.
-Chris
On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
I also plan to use the SWIG agg wrapper
--
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
Chris.Barker@...236...
mpl1/mpl1.py uses it.... It is available in matplotlib installs as
from matplotlib import agg.
The SWIG code is in the swig dir in mpl svn, and there is a partially
broken example in examples/agg_test.py
JDH
On 7/20/07, Christopher Barker <Chris.Barker@...236...> wrote:
> On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
>> I also plan to use the SWIG agg wrapperWhere can I find that? I did some googling, and no luck.
= Data copying =
Push the data to the backend only once, or only when required. Update
the transforms in the backend, but do not push transformed data on
every draw. This is potentially a major win, because we currently
move the data around on every draw.
Does the backend keep a copy of the untransformed data around, so that it can easily create new transformed data when its transform is updated? If so, is there a coherent mechanism for invalidating a piece of data that is being graphed in multiple plots? If not, then how does hittesting determine the correct index into the data (since, presumably, hittesting will require the exact transform in the backend)?
= Transformations =
Support a normal transformation architecture. The current draft
implementation assumes one nonlinear transformation, which happens at
a high layer, and all transformations after that are affines. In the
mpl1 draft, there are three affines: the transformation from view
limits -> axes units (AxesCoords.affineview), the transformation from
axes units to normalized figure units (AxesCoords.affineaxes), and the
transformation from normalized figure units to display
(Renderer.affinerenderer)Do we want to use 3x3 or 4x4 to leave the door open for 3D developers?
I admit the temptation of having basic 3D support, but the problem is that it really doesn't scale well in software. Even the simple blits that we do in Chaco start to hit their limits on big, high-res LCDs that are getting cheaper every day. The approach that I think we're going to have to take in Chaco is to only let 3D be available when using the OpenGL backend, and to restrict the Agg-based backends to be 2D only.
Of course, I'm thinking about all this from an interactive standpoint, so if speed is not a concern, then there's no reason not to build in 3D support from the get-go.
How do transformations (linear and nonlinear) play with Axis features
(ticking and gridding). The ideal is a framework in which ticking,
gridding and labeling work intelligently with arbitrary, user
supplied, transformations. What is the proper transformation API?
This is something we've been puzzling over for Chaco as well. Dave Kammeyer pointed out long ago that the problem with trying to write a generic axis/grid renderer while supporting arbitrary transformations is that straight lines become curves under arbitrary transforms. The basic idea is that the backend (or GraphicsContext, in the Chaco world) needs to provide transformation-aware implementations of line_to() that automatically convert line segments into bezier curves while at the same time providing drawing methods that are guaranteed to be "straight" or aligned with screen coordinates. This way, you can get curved axes in a hyperbolic space "for free", while your ticks stay perfectly straight and the label text is screen-aligned. (Of course, to be perfectly accurate, you would need to handle polar coordinates in a special way anyway.)
= Objects that talk to the backend "primitives" =
Have just a few, fairly rich obects, that the backends need to
understand. Clear candidates are a Path, Text and Image, but despite
their names, don't confuse these with the eponymous matplotlib
matplotlib Artists, which are higher level than what I'm thinking of
here (eg matplotlib.text.Text does *a lot* of layout, and this would
be offloaded ot the backend in this conception of the Text primitive).
Each of these will carry their metadata, eg a path will carry its
stroke color, facecolor, linewidth, etc..., and Text will carry its
font size, color, etc.... We may need some optimizations down the
road, but we should start small. For now, let's call these objects
"primitives".= How much of an intermediate artist layer do we need? =
Do we want to create high level objects like Circle, Rectangle and
Line, each of which manage a Path object under the hood? Probably,
for user convenience and general compability with matplotlib. By
using traits properly here, many current matplotlib Arists will be
thin interfaces around one or more primitives.
I included these two together because I think they both concern a very fundamental matter, which is the drawing model. If you are going to create higher-level "primitives" which encapsulate state (e.g. color, dash style, line width), then you are moving significantly away from the model of a Canvas as just a place to dump pixels/vector drawing commands, and more towards the model of Canvas as a container of stateful objects. But as soon as you do this, a whole host of questions pop up... Are the Circle, Rectangle, etc. in the "intermediate artist layer" objects in their own right, with parameters like 'radius', 'position', etc., or are they just convenience functions to create more low-level primitives on the Canvas? If the former, then you have suddenly have a hierarchical Canvas. If the latter, then is there any structure to how these primitives are held in the Canvas? Even if they are just held in a simple list, are they drawn in the same order as they appear in that list? If they were inserted by a single Circle or Rectangle intermediate artist, is there any way to ensure that they maintain coherency when re-ordering that draw order?
Also, if you have a list of these primitives, it seems natural to hittest against them for picking and interaction. Does this also happen in the same order that they appear in the list? Is there a straightforward way to make them process events in a different order? If you have lots of these little primitives, are there optimizations you can design in so that you don't have to hittest thousands of little primitives on each mouse_move event?
= Where do the plot functions live? =
In matplotlib, the plot functions are matplotlib.axes.Axes methods and
I think there is consensus that this is a poor design. Where should
these live, what should they create, etc?
Well, you can probably guess my answer to this question. 
It seems to me that if you're going to have a drawing model that supports stateful graphics on a canvas, plot renderers should just be glorified graphics that live on the canvas, no different from a Circle or a Rectangle or whatnot. In this case, the plot functions then just become convenience functions that create these graphics and stick them on a canvas.
I think the whole matplotlib.collections module is poorly designed,
and should be chucked wholesale, in favor of faster, more elegant,
optimizations and special cases. Just having the right Path object
will reduce the need for many of these, eg LineCollection,
PolygonCollection, etc... Also, everything should be numpy enabled,
and the sequence-of-python-tuples approach that many of the
collections take should be dropped. Obviously some of the more useful
things there, like quad meshes, need to be ported and retained.
In Chaco we can get interactive speeds just by having a few fast drawing calls at the Kiva layer: lines(), line_set(), draw_marker_at_points(). These were quite easy to implement in both the Agg and Quartz backends. We've talked about introducing another set of drawing commands that allow passing in a "style index" with every point, so that we can speed up our colormapped scatter plots and eventually do colormapped lines and such.
= Z-ordering, containers, etc =
Peter has been doing a lot of nice work on z-order and layers for
chaco, stuff that looks really useful for picking, interaction, etc...
We should look at this approach, and think carefully about how this
should be handled. Paul may be a good candidate for this, since he
has been working recently on the picking API.
I think that you should really consider integrating the event propagation model with the drawing model. The Chaco model of "containers of graphical components" is pretty straightforward and even though we've implemented it in pure python, it is responsive enough for interactivity. The nice thing about it is that there's nothing in the container/component model that is intrinsically related to plotting, so you can use it to build simple widgets that play nicely with the rest of your plot because they use the same event propagation and component drawing model. I can put together some more thorough documentation on all this, if folks are interested.
I also plan to use the SWIG
agg wrapper, so this gets rid of _backend_agg. If we can enhance the
SWIG agg wrapper, we can also do images through there, getting rid of
_image.cpp. Having a fully featured, python-exposed agg wrapper will
be a plus in mpl and beyond. But with the agg license change, I'm
open to discussion of other approaches.
How exactly are you guys wrapping Agg? I guess I need to take a look at that stuff in more detail... Kiva has been fairly stable, even though we don't do much maintenance on it, and the DisplayPDF drawing model has worked out fairly well. After Robert put together the Quartz backend for it, we can nicely verify that our Agg-based implementation of DisplayPDF is fairly good, since our plots render the same on Windows and Mac. If we had just put in a little more effort on optimization for Linux and cleaning up some outdated cruft, I think it would be in really good shape. Additionally, Phil Thompson is going to be working on porting Kiva and Enable to Qt. Kiva's Agg backend is based on Agg 2.4, which is still BSD.
The major missing piece in ft2font, which is a pretty elaborate CXX
module. Michael may want to consider alternatives, including looking
at the agg support for freetype, and the kiva/chaco approach.
Unfortunately, Chaco's font handling isn't anything to write home about.. I think the world is crying out for a nice Python library for font lookup and font metrics.
= Traits =
I think we should make a major committment to traits and use them from
the ground up. Even without the UI stuff, they add plenty to make
them worthwhile, especially the validation and notification features.
With the UI (wx only) , they are a major win for many GUI developers.
Compare the logic for sharing an x-axis using matplotlib transforms
with Axes.sharex with the approach used in mpl1.py with sync_trait-ed
affines.
Once you start using trait events and notifications extensively, you won't want to go back. It encourages a very componentized model of development that is both a world apart from normal OOP while at the same time feeling very natural.
= Axis handling =
The whole concept of the Axes object needs to be rethought, in light
of the fact that we need to support multiple axis objects on one Axes.
The matplotlib implementation assumes 1 xaxis and 1 yaxis per Axes,
and we hack two y-axis support (examples/two_scales.py) with some
transform shenanigans via twinx and multiple Axes where one is hidden,
but the approach is not scalable and is unwieldy.This will require a fair amount of thought, but we should aim for
supporting an arbitrary number of axis obects, presumably associated
with individual artists or primitives.
...
The other important featiure for axis support is that, for the most
part, they should be arbitrarily placeable (eg a "detached" axis).
I think you should consider separating the two concerns that are being overloaded onto the Axis object: (1) an axis represents a range in data space that controls the transforms/mappings between data and screen space, and (2) an axis is a visual component that needs to be rendered at a particular place on the screen and receives events from the user (e.g. double-clicking to set its parameters).
If you create a separate DataRange object, then you can use it to drive one or more Transforms as well as multiple Axis objects. This is basically how Chaco gets synchronized axes for "free". The actual graphical Axis objects can render themselves however they want to, and their actual layout on the screen (on opposite sides of a plot, piled up in a stack on the left or right, etc.) is determined by a layout mechanism that is completely orthogonal to the issues of mapping. This also allows for "detached" axes and such.
= Chaco and Kiva =
It is a good idea for an enterprising developer to take a careful look
at the current Chaco and Kiva to see if we can further integrate with
them. I am gun shy because they seem formiddable and complex, and one
of my major goals here is to streamline and simplify, but they are
incredible pieces of work and we need to carefully consider them,
especially as we integrate other parts of the enthought suite into our
core, eg traits, increasing the possibility of synergies.
I really glad to read this, because I think there are clearly a lot of common problems that we all have to solve. At its core, Chaco is not *that* complex - it's just rather poorly documented, and that is no one's fault but mine. The structure, however, is really pretty straightforward. Its container/component model is not much more complicated than what a minimal solution to some of the problems I've outlined in previous paragraphs would entail.
I guess the key question I would ask is this: What is the vision, or driving purpose, behind mpl1? Is it to develop a better backend architecture for pylab, or something more? I ask this because some of the designs you have proposed for various pieces of mpl1 look very much like they are trying to solve the same problems that we're trying to solve in Chaco; if you really are quite prepared to "break the hell out of matplotlib", I think that now would be a really good time for collaboration.
-Peter
On Jul 19, 2007, at 12:18 PM, John Hunter wrote:
Also, everything should be numpy enabled,
and the sequence-of-python-tuples approach that many of the
collections take should be dropped.who hoo!
However, numpy doesn't handle "ragged" arrays well. I wonder if there's
a good way to implement those, so that transforms can be done
numpy-efficient.
Pad with NaNs?
= Chaco and Kiva =
It is a good idea for an enterprising developer to take a careful look
at the current Chaco and KivaOK. I have to ask -- why aren't we all just using Chaco? I know I'm not
because ??years ago, Enthought was not really supporting anything but
Windows -- is that still true? Would it be a whole lot less work to
support GTK, OS-X, ??? in Chaco than keep developing a separate lib?
Most of ETS is being developed, tested, and run on Windows, Mac, and Linux every day. We now have eggs for windows and mac and some flavors of linux (fedora, ubuntu). Long ago we factored out Chaco's underlying drawing layer into a package called Kiva. Kiva has Agg-based backends for wxWindows on X11 and Win32, and a native Quartz backend for wxWindows on OS X. There is also a PIL-based non-interactive raster backend. Kiva's PS, PDF, SVG, and GL backends could all use a little love, but they were functioning at one point in time.
-Peter
On Jul 19, 2007, at 5:31 PM, Christopher Barker wrote:
= Z-ordering, containers, etc =
Peter has been doing a lot of nice work on z-order and layers for
chaco, stuff that looks really useful for picking, interaction, etc...
We should look at this approach, and think carefully about how this
should be handled.Is there somewhere in particular that I can look to see what Peter's been working on? Enthought's svn repositories?
I would recommend grabbing the eggs:
https://svn.enthought.com/enthought/wiki/InstallWithEggs
After installing the eggs, you can grab the chaco2 examples from SVN:
svn co https://svn.enthought.com/svn/enthought/branches/enthought.chaco2_2.0/examples
Let me know if you have any problems!
= Traits =
I think we should make a major committment to traits and use them from
the ground up. Even without the UI stuff, they add plenty to make
them worthwhile, especially the validation and notification features.I hate to be the first one to disagree, but here goes: traits give me the heebie-jeebies. I agree that matplotlib 1.0/2.0 needs to validate all user-settable parameters. However, I'm concerned about the development overhead that might result from making traits as a core dependency. Code readability is also a concern to me -- the experience of reading mpl1.py suggests to me that newcomers might find traits a bit too "voodoo". I'm confident that the same thing could be achieved using Python properties to validate attributes.
This is a true statement. In fact, the first version of traits basically used properties to implement a lot of the validation and notification. Eventually for power and speed, we moved to using a metaclass with a C extension.
I think the code readability question comes down to "is it easier for someone to learn some basic things about traits, or is it easier for them to decipher the massive jumble of property setters and getters I've wired up"? I think that the amount of duplicated code that has to written using simple python properties is non-trivial. Of course, this being Python, people are going to be tempted to write some code to generate code or at least do some simple metaprogramming when they are faced with writing their 50th setter/getter. This then leads to the problem of documenting and testing the code-generating functions, and newcomers will have to learn about those and what they mean and what their side effects are. With traits, there is at least a well-tested and documented design that has been through the ringer a few times.
Change notification is another matter, granted, but I think that a major rewrite will provide the opportunity to better design for those situations.
I actually think that change notification, more so than validation, is the killer feature of traits. After you write enough code with objects that communicate via notifications, you start really thinking of your running program as a little ecosystem of live objects, and it's an entirely different mental model for design and implementation. It's especially reinforced if you use Traits UI to bring up dialogs to interact with these live objects, or use IPython to start twiddling them as they're running, and you can see things change realtime, automagically.
Just my (slight biased) $.02.
-Peter
On Jul 19, 2007, at 10:42 PM, Ken McIvor wrote:
In retrospect, I should've been clearer about my objection to using traits in mpl1. I don't have any problem with enthought.traits in an abstract sense -- it seems like an excellent solution to the problems of attribute validation and change notification. My concerns regard building a backend rendering system that uses change notifications to maintain graphics state. I believe this approach makes the rendering system harder to understand and optimize.
Since my original comment about traits I have been working hard to put my money where my mouth is. Attached is an experimental rendering system with an alternative transform architecture that does not require attribute change notification. Please let me know what you think, everybody.
Ken
mpl1_displaypdf.py (27.5 KB)
On Jul 23, 2007, at 7:18 PM, Peter Wang wrote:
On Jul 19, 2007, at 10:42 PM, Ken McIvor wrote:
Code readability is also a concern to me -- the experience of reading mpl1.py suggests to me that newcomers might find traits a bit too "voodoo". I'm confident that the same thing could be achieved using Python properties to validate
attributes.This is a true statement. In fact, the first version of traits
basically used properties to implement a lot of the validation and
notification. Eventually for power and speed, we moved to using a
metaclass with a C extension.I think the code readability question comes down to "is it easier for
someone to learn some basic things about traits, or is it easier for
them to decipher the massive jumble of property setters and getters
I've wired up"? I think that the amount of duplicated code that has
to written using simple python properties is non-trivial.
AFAIK chaco is based on this approach. It makes a very nice API to use in
interactive programs. As far as understanding and optimizing it would be
nice to see if Peter Wang has something to say about this.
Ga�l
On Tue, Jul 24, 2007 at 10:31:05AM -0500, Ken McIvor wrote:
In retrospect, I should've been clearer about my objection to using
traits in mpl1. I don't have any problem with enthought.traits in an
abstract sense -- it seems like an excellent solution to the problems
of attribute validation and change notification. My concerns regard
building a backend rendering system that uses change notifications to
maintain graphics state. I believe this approach makes the rendering
system harder to understand and optimize.
AFAIK chaco is based on this approach.
Not as such. Chaco uses traits for its high-level plot objects but the rendering system, Kiva, does not appear to use traits all.
mpl1.py is using traits to maintain pre-calculated affine transformation matrices and graphics styles for each plot object. I believe this approach is confusing and results in rendering code that is hard to understand and optimize.
It makes a very nice API to use in interactive programs.
I agree that an attribute-based API would much nicer for the high-level plot objects like Figure and Axes. However, I don't think traits are a technical necessity to accomplish that goal.
As far as understanding and optimizing it would be nice to see if Peter Wang has something to say about this.
It would be great to learn how Chaco/Kiva caches the things that I think of as "canvas primitives", like native AGG paths. I'd also be interested in learning how the transformation model is implemented in Chaco.
Ken
On Jul 24, 2007, at 10:46 AM, Gael Varoquaux wrote:
Peter Wang wrote:
OK. I have to ask -- why aren't we all just using Chaco?
Most of ETS is being developed, tested, and run on Windows, Mac, and Linux every day.
Ah, great to know -- that was decidedly not the case the last time I took a good look at Chaco.
Long ago we factored out Chaco's underlying drawing layer into a package called Kiva.
That was there from the beginning if I recall, which is great.
> Kiva's PS, PDF, SVG, and GL backends
could all use a little love, but they were functioning at one point in time.
Sorry to play devil's advocate here, but the question remains -- MPL developers (John, primarily, I suppose):
Why not dump MPL1, and work on a nice pylab-like front end to Chaco, while giving the "love" to the Kiva PS, PDF, SVG back-ends (and add GTK -- if it's not there)?
Most users, like me, just want something that does the job for us. I know I'm going to take a look at Chaco again.
Add the skills of the MPL team to Chaco, and it could really shine!
-Chris
On Jul 19, 2007, at 5:31 PM, Christopher Barker wrote:
--
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
Chris.Barker@...236...
I could quickly find myself out of my depth on this topic, so I'll just make a
couple quick points. I need to create plots for qt4 projects at my lab, and I
have grown really accustomed to the quality of mpl's eps output when usetex
is enabled.
Darren
On Tuesday 24 July 2007 6:43:03 pm Chris Barker wrote:
Sorry to play devil's advocate here, but the question remains -- MPL
developers (John, primarily, I suppose):Why not dump MPL1, and work on a nice pylab-like front end to Chaco,
while giving the "love" to the Kiva PS, PDF, SVG back-ends (and add GTK
-- if it's not there)?Most users, like me, just want something that does the job for us. I
know I'm going to take a look at Chaco again.Add the skills of the MPL team to Chaco, and it could really shine!
Darren Dale wrote:
I need to create plots for qt4 projects at my lab, and I have grown really accustomed to the quality of mpl's eps
So we need QT and EPS.
output when usetex is enabled.
Ah! and some good math implementation -- What does Chaco do for that? I know I took part in a discussion about it on a Chaco list a few years back -- at the time I argued that you're never going to do as well at TeX.
These aren't deal-breakers so far -- it sounds like Kiva has at least rudimentary QT support -- and I imagine a MPL usetex-like approach could be applied to Chaco too (though I'd rather see the DVI parsed and rendered by Kiva...)
-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
Chris.Barker@...236...
We've also had this discussion internally a bit. It usually concludes with us wishing that someone would just port jsmath to Python, or implement Knuth's TeX layout rules in Python.
Currently Chaco2 doesn't have a math markup mechanism, but it was fairly trivial for me to port mpl's mathtext to Chaco1. I didn't bother moving that to Chaco2 because I really wanted to figure out a way to do "real" TeX layout that would still fit into the interactive model.
-Peter
On Jul 24, 2007, at 7:31 PM, Chris Barker wrote:
output when usetex is enabled.
Ah! and some good math implementation -- What does Chaco do for that? I
know I took part in a discussion about it on a Chaco list a few years
back -- at the time I argued that you're never going to do as well at TeX.
Well I want TeX. I want to be able to do my TeX hacks on my figures. And
I do believe there is a lot of work to be done before you can do better
than TeX.
My 2 cents,
Ga�l
On Tue, Jul 24, 2007 at 05:31:17PM -0700, Chris Barker wrote:
> output when usetex is enabled.
Ah! and some good math implementation -- What does Chaco do for that? I
know I took part in a discussion about it on a Chaco list a few years
back -- at the time I argued that you're never going to do as well at TeX.
What kind of TeX hacks do you want to use on figures? My TeX hacks
include mostly things like using negative vspace to squeeze more text
into a 6-page paper.
--bb
On 7/25/07, Gael Varoquaux <gael.varoquaux@...427...> wrote:
On Tue, Jul 24, 2007 at 05:31:17PM -0700, Chris Barker wrote:
> > output when usetex is enabled.> Ah! and some good math implementation -- What does Chaco do for that? I
> know I took part in a discussion about it on a Chaco list a few years
> back -- at the time I argued that you're never going to do as well at TeX.Well I want TeX. I want to be able to do my TeX hacks on my figures. And
I do believe there is a lot of work to be done before you can do better
than TeX.