Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
You can subscribe to this list here.
2003 
_{Jan}
(1) 
_{Feb}
(2) 
_{Mar}
(6) 
_{Apr}
(11) 
_{May}

_{Jun}
(2) 
_{Jul}

_{Aug}
(1) 
_{Sep}
(15) 
_{Oct}
(12) 
_{Nov}
(11) 
_{Dec}
(18) 

2004 
_{Jan}
(57) 
_{Feb}
(16) 
_{Mar}
(3) 
_{Apr}
(14) 
_{May}
(35) 
_{Jun}
(41) 
_{Jul}
(19) 
_{Aug}
(25) 
_{Sep}
(14) 
_{Oct}
(36) 
_{Nov}
(41) 
_{Dec}
(29) 
2005 
_{Jan}
(44) 
_{Feb}
(21) 
_{Mar}
(17) 
_{Apr}
(45) 
_{May}
(23) 
_{Jun}
(26) 
_{Jul}
(30) 
_{Aug}
(9) 
_{Sep}
(120) 
_{Oct}
(34) 
_{Nov}
(17) 
_{Dec}
(6) 
2006 
_{Jan}
(23) 
_{Feb}
(56) 
_{Mar}
(78) 
_{Apr}
(14) 
_{May}
(87) 
_{Jun}
(52) 
_{Jul}
(69) 
_{Aug}
(41) 
_{Sep}
(53) 
_{Oct}
(37) 
_{Nov}
(8) 
_{Dec}
(17) 
2007 
_{Jan}
(32) 
_{Feb}
(3) 
_{Mar}
(21) 
_{Apr}
(29) 
_{May}
(14) 
_{Jun}
(9) 
_{Jul}
(30) 
_{Aug}
(26) 
_{Sep}
(6) 
_{Oct}
(9) 
_{Nov}
(7) 
_{Dec}
(6) 
2008 
_{Jan}
(9) 
_{Feb}
(19) 
_{Mar}
(46) 
_{Apr}
(44) 
_{May}
(28) 
_{Jun}
(32) 
_{Jul}
(37) 
_{Aug}
(14) 
_{Sep}
(7) 
_{Oct}
(3) 
_{Nov}
(15) 
_{Dec}
(3) 
2009 
_{Jan}

_{Feb}
(6) 
_{Mar}
(7) 
_{Apr}

_{May}
(20) 
_{Jun}
(8) 
_{Jul}
(5) 
_{Aug}
(6) 
_{Sep}

_{Oct}
(45) 
_{Nov}
(8) 
_{Dec}
(20) 
2010 
_{Jan}
(3) 
_{Feb}
(1) 
_{Mar}
(12) 
_{Apr}

_{May}
(3) 
_{Jun}
(12) 
_{Jul}
(1) 
_{Aug}
(2) 
_{Sep}
(3) 
_{Oct}
(11) 
_{Nov}
(5) 
_{Dec}
(6) 
2011 
_{Jan}
(4) 
_{Feb}

_{Mar}

_{Apr}
(13) 
_{May}
(9) 
_{Jun}
(12) 
_{Jul}
(12) 
_{Aug}
(2) 
_{Sep}
(11) 
_{Oct}
(8) 
_{Nov}
(2) 
_{Dec}
(16) 
2012 
_{Jan}
(23) 
_{Feb}

_{Mar}

_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}
(6) 
_{Oct}
(7) 
_{Nov}

_{Dec}
(3) 
2013 
_{Jan}
(1) 
_{Feb}

_{Mar}

_{Apr}
(2) 
_{May}
(7) 
_{Jun}
(6) 
_{Jul}
(2) 
_{Aug}
(12) 
_{Sep}

_{Oct}
(3) 
_{Nov}

_{Dec}
(3) 
2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}
(5) 
_{Mar}
(5) 
_{Apr}
(1) 
_{May}
(7) 
_{Jun}
(28) 
_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}
(2) 
_{Nov}
(3) 
_{Dec}
(10) 
2016 
_{Jan}
(16) 
_{Feb}
(6) 
_{Mar}

_{Apr}

_{May}
(9) 
_{Jun}
(5) 
_{Jul}
(6) 
_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}

2017 
_{Jan}

_{Feb}
(5) 
_{Mar}
(3) 
_{Apr}
(4) 
_{May}
(7) 
_{Jun}

_{Jul}
(1) 
_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}

2018 
_{Jan}

_{Feb}
(4) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1
(4) 
2
(2) 
3
(2) 
4

5
(3) 
6
(4) 
7
(5) 
8
(10) 
9
(7) 
10
(2) 
11
(1) 
12
(14) 
13
(6) 
14
(11) 
15
(4) 
16
(5) 
17
(2) 
18

19
(7) 
20

21
(5) 
22
(12) 
23
(3) 
24

25

26

27
(1) 
28
(1) 
29
(3) 
30
(6) 

From: Michael Schindler <mschindler@us...>  20050914 22:36:25

Hello Rich, On 14.09.05, Rich Drewes wrote: > I'm having a lot of trouble getting absangle1= and absangle2= on curve()s > to do what I expect. This may be because what I expect it to do is not > what it is supposed to dothe documentation is a bit brief on what they > do. > > What I *think* absangle is supposed to do is define the absolute angle of > entry of my connector curve into the object being connected to. In my > case, I am connecting polygons, mostly just boxes. So absangle2=0 would > mean that my arrow would enter the target from the left (or maybe the > right, wherever 0 is defined . . . already things are a bit hazy). If > absangle2=90 the target would be entered from the top of the object (or > maybe bottom, depending on which direction things are counted.) > > (Or, rather than connecting to the edge of the target at the angle given > by the side, does it merely instruct the curve drawer to connect to some > convenient side of the target, but connect to it at the indicated angle of > incidence?) When giving the orientation angle, I always think in terms of the tangent vector of the path (heading in the direction that the path is drawn: along positive parameterization). The coordinate system is such that an angle of 0 degrees means "heading right" and 90 degrees means "heading top" Therefore, if you want something like this: _ _ _ > _ then use absangle1=0, absangle2=0 _______ / \    v _ _ then use absangle1=90, absangle2=90 and so on. For the relative angles, things are different. Here, I try to be consistent with the arc() connector, where both relative angles are the same. Therefore, the coordinate systems at the two boxes have different signs. The absolute values of relangle1 and relangle2 are the (absolute) angles between the connector and the straight connection line between the box centers. Their sign gives the side on which they start: When they have the same sign, the whole connectors stays on the same side. I admit that there are many different coordinate systems for these angles. Maybe we should turn the sign of relangle2. This is a point that can be discussed. > The absangle arguments seem to have more effect when my polygons are > smaller. If my polygons are more elongated, my absangle commands seem to > be ignored consistently by whatever actually placed my connector curves. In order to convince me that something strange happens, please enclose a short example. This is what the connectors do: 1. draw a line/curve/arc from one boxcenter to the other boxcenter The centers are the important orientation points for connectors. If you are using textboxes, then the center will be on the baseline of the text, at the leftmost point (unless you use text.halign.xxx) 2. intersect this line/curve/arc with the box' outline path (polygons in your case) 3. shorten the line/curve/arc according to the boxdists parameter Note that all angles are evaluated at the box' center. This means that when you connect a pair of boxes, first large boxes, and then small ones, and then compare, the global slopes of the two connectors will be the same, but the angle at the different box' outlines will, of course, be different. > See http://www.interstice.com/drewes/brain/pyxdocexample.eps for an > example of what I am trying to do. As you can see, I have to be pretty > careful about how the connectors are placed to make sure the result is > legible. > I suspect I am working under at least one major misconception here. I hope my explanations are helpful, and I will improve the documentation at this point. Michael.  "A mathematician is a device for turning coffee into theorems" Paul Erdös. 
From: Rich Drewes <drewes@in...>  20050914 21:34:26

I'm having a lot of trouble getting absangle1= and absangle2= on curve()s to do what I expect. This may be because what I expect it to do is not what it is supposed to dothe documentation is a bit brief on what they do. What I *think* absangle is supposed to do is define the absolute angle of entry of my connector curve into the object being connected to. In my case, I am connecting polygons, mostly just boxes. So absangle2=0 would mean that my arrow would enter the target from the left (or maybe the right, wherever 0 is defined . . . already things are a bit hazy). If absangle2=90 the target would be entered from the top of the object (or maybe bottom, depending on which direction things are counted.) (Or, rather than connecting to the edge of the target at the angle given by the side, does it merely instruct the curve drawer to connect to some convenient side of the target, but connect to it at the indicated angle of incidence?) The absangle arguments seem to have more effect when my polygons are smaller. If my polygons are more elongated, my absangle commands seem to be ignored consistently by whatever actually placed my connector curves. See http://www.interstice.com/drewes/brain/pyxdocexample.eps for an example of what I am trying to do. As you can see, I have to be pretty careful about how the connectors are placed to make sure the result is legible. I suspect I am working under at least one major misconception here. Thanks, Rich 
From: Andre Wobst <wobsta@us...>  20050914 11:59:57

On 14.09.05, Joerg Lehmann wrote: > > > > Its fine as long as a and b are not close to zero. For this case two > > > > problems occur: First scale does not work as expected (for a or b > > > > being exactly zero). Jörg, do you remember what the idea was? > > > > > > Then the transformation matrix becomes degenerate, which we somehow > > > wanted to exclude at that time. Maybe, we shouldn't be too strict about > > > that, at least if PostScript doesn't complain in such a case (I didn't > > > check). > > > > I didn't either. Maybe that's the point. Otherwise I don't see any > > reason for this restriction. Beside that the checks are strange, > > they're even wrong for the case of b=0, which lead to a circle instead > > of a line. Again, a marker issue here ... ;) > > According to PLRM, p. 189, transformation with determinant zero are "not > very useful" and can lead to undefinedresult errors "during the > execution of graphics and font operators". Oh well, not a very useful > statement for a reference either. In some sense, right. But it tells us, that we should not put something out, which has determinant 0. We can savely always point at someone else, when somebody somes with it. We basically have to ensure that the trafo can be inverted. (We should also keep in mind, that it's something else we're having in our variables than what we write into a file, but at least in PostScript we always write enough digits by the %g to never create spurious zeros, and for PDF I would just ignore the issue for the moment.) Beside that the sy=0 in trafo.scale silently leads to sy=sx which is still an error and has nothing to do with this discussion. > > Well, the ellipse should just work. Suppose you're using it in a graph > > style with flexible size given by the data values you put in. Like for > > circles in the first graphstyle example. It just shouldn't break. It > > doesn't even break for negative values so why should it for zero or > > something close to zero ... > > I really don't know. But I would tend to attempt preventing PS code > which is not leading to errors. +1 Hence there is such a statement in PLRM, I would suggest to introduce another epsilon for the determinante and a TrafoError to be raised on failure. It sounds a bit like overkill, but its (a) easy to implement, (b) fits into what we're doing elsewhere and (c) should never hurt. Still you can't create an trafo projection (with determinante != 1, i.e. with determinante = 0), but well, that's what's forbidden in PostScript. We can than think about the problem I had with the ellipse and according to the discussion with the arc connector, we should return a "closed line" for a or b being 0 and a circle of radius 0 for a and b being 0. (The being zero should be read as an almost zero taking into account the trafo._epsilon and/or the normpath._epsilon.) And that's it ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Joerg Lehmann <joergl@us...>  20050914 11:34:59

On 14.09.05, Andre Wobst wrote: > On 14.09.05, Joerg Lehmann wrote: > > > On 13.09.05, Dani Marti wrote: > > > > What is the most straightforward way to plot an ellipse (or something > > > > that looks like an ellipse, like a deformed circle)? Is any predefined > > > > path for an ellipse? > > > > > > def elipse(x, y, a, b, angle): > > > t = trafo.scale(unit.topt(a), unit.topt(b)).rotated(angle).translated(x, y) > > > return path.circle_pt(0, 0, 1).transformed(t) > > > > Btw, this makes another class/factory function for our future paths > > module... > > Right. > > > > Its fine as long as a and b are not close to zero. For this case two > > > problems occur: First scale does not work as expected (for a or b > > > being exactly zero). Jörg, do you remember what the idea was? > > > > Then the transformation matrix becomes degenerate, which we somehow > > wanted to exclude at that time. Maybe, we shouldn't be too strict about > > that, at least if PostScript doesn't complain in such a case (I didn't > > check). > > I didn't either. Maybe that's the point. Otherwise I don't see any > reason for this restriction. Beside that the checks are strange, > they're even wrong for the case of b=0, which lead to a circle instead > of a line. Again, a marker issue here ... ;) According to PLRM, p. 189, transformation with determinant zero are "not very useful" and can lead to undefinedresult errors "during the execution of graphics and font operators". Oh well, not a very useful statement for a reference either. > Well, the ellipse should just work. Suppose you're using it in a graph > style with flexible size given by the data values you put in. Like for > circles in the first graphstyle example. It just shouldn't break. It > doesn't even break for negative values so why should it for zero or > something close to zero ... I really don't know. But I would tend to attempt preventing PS code which is not leading to errors. Jörg 
From: Andre Wobst <wobsta@us...>  20050914 11:16:23

Hi, On 13.09.05, Rich Drewes wrote: > The "angle" argument doesn't seem to result in rotations of the placed > text. Is it supposed to? No, it's the direction used for alignment. We could (and even should at least have an option to) do this perpendicular to the path. To come back to your original question, you should add a rotation to the textattrs. Unfortunately you'll overwrite the text.halign.center and text.vshift.mathaxis by that. The PyXway would be to merge those attributes the the additional attributes. So the code would look like: class textdeco(deco.deco, attr.attr): def __init__(self, text, textattrs=[], angle=0, textdist=0.2, relarcpos=0.5, texrunner=text.defaulttexrunner): self.text = text self.textattrs = textattrs self.angle = angle self.textdist = textdist self.relarcpos = relarcpos self.texrunner = texrunner def decorate(self, dp): x, y = dp.path.at(self.relarcpos * dp.path.arclen()) textattrs = attr.mergeattrs([text.halign.center, text.vshift.mathaxis] + self.textattrs) t = self.texrunner.text(x, y, self.text, textattrs) t.linealign(self.textdist, math.cos(self.angle*math.pi/180), math.sin(self.angle*math.pi/180)) dp.ornaments.insert(t) return dp c = canvas.canvas() c.stroke(path.curve(0, 0, 3, 0, 2, 5, 5, 5), [textdeco("Hello, world!", textattrs=[trafo.rotate(45)])]) c.writeEPSfile("textdeco") André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20050914 08:41:12

On 14.09.05, Joerg Lehmann wrote: > > On 13.09.05, Dani Marti wrote: > > > What is the most straightforward way to plot an ellipse (or something > > > that looks like an ellipse, like a deformed circle)? Is any predefined > > > path for an ellipse? > > > > def elipse(x, y, a, b, angle): > > t = trafo.scale(unit.topt(a), unit.topt(b)).rotated(angle).translated(x, y) > > return path.circle_pt(0, 0, 1).transformed(t) > > Btw, this makes another class/factory function for our future paths > module... Right. > > Its fine as long as a and b are not close to zero. For this case two > > problems occur: First scale does not work as expected (for a or b > > being exactly zero). Jörg, do you remember what the idea was? > > Then the transformation matrix becomes degenerate, which we somehow > wanted to exclude at that time. Maybe, we shouldn't be too strict about > that, at least if PostScript doesn't complain in such a case (I didn't > check). I didn't either. Maybe that's the point. Otherwise I don't see any reason for this restriction. Beside that the checks are strange, they're even wrong for the case of b=0, which lead to a circle instead of a line. Again, a marker issue here ... ;) > But for the present case, this is pointless anyway. Not really, it just shouldn't break. See below. > > I don't > > remember/understand it. (A solution could be to change the trafo.scale > > or to build our own transformation matrix.) The second problem is > > related to the transformed on a small closed object (when a and b are > > both almost zero, say 1e10). The later can be solved by > > ".normpath(epsilon=None).transformed(t).path()" instead of just > > ".transformed(t)". (Jörg, Michael: Here we have a second usecase for > > the recent addition of the epsilon=None feature ... ;)). > > I don't know why this case should be too problematic. Who wants such > an ellipse? Well, the ellipse should just work. Suppose you're using it in a graph style with flexible size given by the data values you put in. Like for circles in the first graphstyle example. It just shouldn't break. It doesn't even break for negative values so why should it for zero or something close to zero ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Joerg Lehmann <joergl@us...>  20050914 08:14:44

On 14.09.05, Andre Wobst wrote: > Hi, > > On 13.09.05, Dani Marti wrote: > > What is the most straightforward way to plot an ellipse (or something > > that looks like an ellipse, like a deformed circle)? Is any predefined > > path for an ellipse? > > def elipse(x, y, a, b, angle): > t = trafo.scale(unit.topt(a), unit.topt(b)).rotated(angle).translated(x, y) > return path.circle_pt(0, 0, 1).transformed(t) Btw, this makes another class/factory function for our future paths module... > Its fine as long as a and b are not close to zero. For this case two > problems occur: First scale does not work as expected (for a or b > being exactly zero). Jörg, do you remember what the idea was? Then the transformation matrix becomes degenerate, which we somehow wanted to exclude at that time. Maybe, we shouldn't be too strict about that, at least if PostScript doesn't complain in such a case (I didn't check). But for the present case, this is pointless anyway. > I don't > remember/understand it. (A solution could be to change the trafo.scale > or to build our own transformation matrix.) The second problem is > related to the transformed on a small closed object (when a and b are > both almost zero, say 1e10). The later can be solved by > ".normpath(epsilon=None).transformed(t).path()" instead of just > ".transformed(t)". (Jörg, Michael: Here we have a second usecase for > the recent addition of the epsilon=None feature ... ;)). I don't know why this case should be too problematic. Who wants such an ellipse? Jörg 
From: Andre Wobst <wobsta@us...>  20050914 06:09:48

Hi, On 13.09.05, Francisco Borges wrote: > > The proper way to solve you original issue (at least as far as I > > understand it), would be to understand, that you can insert things > > below the data and on top of it. To insert something below, you can do > > it before g.data is called and to do it afterwards, insert something > > after that. Note, that you can insert canvas instances as well. So I > > think that's the way to go for you. Suppose you want to stroke > > something now on the graph, but is should occur after the data has > > been inserted. So just stroke it on a canvas, then add further plot > > commands etc. Then finish the graph (or at least call dodata). And > > then insert the canvas into the graph. All stuff in the canvas will > > then be on top of the data, although you create the material before. > > I'm not sure I got your point here :) So let me post a simple example of what I wanted to describe :): from pyx import * c = canvas.canvas() c1 = canvas.canvas() c2 = canvas.canvas() c1.stroke(path.line(0, 0, 1, 0), [color.rgb.red]) c2.stroke(path.line(1, 0, 2, 0), [color.rgb.green]) c.insert(c1) # insert below the text c.text(0, 0, "Hello, world!", [text.vshift.mathaxis]) c.insert(c2) # insert abobe the text c.writeEPSfile("insert") > Anyway I did get that in the future I'll be able to plot after finishing the > layout of the graph and that was the showstopper for me. Right. We'll have this in the future ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20050914 06:04:37

On 13.09.05, Francisco Borges wrote: > I would recommend you guys to add some silly example of graph filling to the > PyX graph examples. All examples there with filling involve rather > complicated path manipulation. But isn't your filling just from the starting and end point of your path a very uncommon task? And once you can stroke something you can also fill it. We might  overall  work on the decorator description, right ... since it is a general concept in PyX and it might not be that easy to gasp at the first ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20050914 06:00:15

Hi, On 13.09.05, Alan G Isaac wrote: > I am having an odd problem: dvipdfm is unhappy with > encapsulated PDFs generated from PyX's EPS output. >  If I use Ghostview's pdfwrite to produce them, I see the > figure but no text. >  If I use epstopdf to produce them, the bounding box > appears not to be honored: the figure is displaced. epstopdf is basically a ghostscript call as well. Which version of ghostscript are you using? Do you have different versions of ghostscript installed at you maschine and they're interfering? The fontproblem you have in one case but not the other sounds a bit like this ... >  I do not see any problems if I view the EPS with > Ghostview. > > This is very odd because dvipdfm is generally extremely > reliable. (By the way, yousing dvips with ps2pdf works > fine, as far as I can tell.) Just to clearify: You're always working with an EPS created by PyX? Than you convert that in several ways and you get into troubles using the resulting EPS? (Why not use the PDF output of PyX? Any troubles with it?) I'm kind of surprised, since I would expect PyX EPS outout to be well well established and kind of stable. Anyway, I would first try to translate the content to a positive bbox. For small figures the most easiest way is to set a paperformat by c.writeEPSfile("test", paperformat=document.paperformat.A4) and the like. If you look into the EPS the bbox info at the beginning should now be positive in all parts (when your fig isn't too big). BTW you can now also just print the EPS on a PostScript printer and the result will be centered on the page. We do know of some cases, where negative bboxes lead to stange behaviours although they should perfectly work. In case you're doing something else or it doesn't help, feal free to post some more details or even an example somewhere on the web (this list is limited to 40 KB per mail) ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 
From: Andre Wobst <wobsta@us...>  20050914 05:45:14

Hi, On 13.09.05, Dani Marti wrote: > What is the most straightforward way to plot an ellipse (or something > that looks like an ellipse, like a deformed circle)? Is any predefined > path for an ellipse? def elipse(x, y, a, b, angle): t = trafo.scale(unit.topt(a), unit.topt(b)).rotated(angle).translated(x, y) return path.circle_pt(0, 0, 1).transformed(t) Its fine as long as a and b are not close to zero. For this case two problems occur: First scale does not work as expected (for a or b being exactly zero). Jörg, do you remember what the idea was? I don't remember/understand it. (A solution could be to change the trafo.scale or to build our own transformation matrix.) The second problem is related to the transformed on a small closed object (when a and b are both almost zero, say 1e10). The later can be solved by ".normpath(epsilon=None).transformed(t).path()" instead of just ".transformed(t)". (Jörg, Michael: Here we have a second usecase for the recent addition of the epsilon=None feature ... ;)). Once the scale thing is cleared, I'll happily add an elipse to the PyX core. In the mean the function above will certainly do ... André  by _ _ _ Dr. André Wobst / \ \ / ) wobsta@..., http://www.wobsta.de/ / _ \ \/\/ / PyX  High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ 