From: Alan G I. <ai...@am...> - 2006-03-13 14:12:39
|
What's the preferred way to put an arrowhead at the midpoint of a line segment? (Like this: http://en.wikipedia.org/wiki/Cobweb_Cycle ) Drawing it in two pieces seems the obvious choice right now, but it seems like there was talk of a decoration for this? Thank you, Alan Isaac |
From: Michael J G. <mic...@fa...> - 2006-03-13 14:48:58
|
Alan G Isaac venit, vidit, dixit 03/13/06 15:18: > What's the preferred way to put an arrowhead at the midpoint > of a line segment? (Like this: http://en.wikipedia.org/wiki/Cobweb_Cycle ) > Drawing it in two pieces seems the obvious choice right now, > but it seems like there was talk of a decoration for this? > > Thank you, > Alan Isaac I had planned to implement this for a complex analysis script. Fortunately, I checked the SVN code before to make sure the interface is still the same. And voila: In SVN, the pos argument of deco.arrow() can be anything between 0 and 1 now (it used be 0 or 1 only). This is in units of arclength. So, 0.5 is the midpoint, although I tend use something like 0.55 (pos is where the tip sits). Thanks, Andre! Cheers, Michael P.S.: Stay tuned for the update to deco.text() ;) |
From: Alan G I. <ai...@am...> - 2006-03-13 15:55:56
|
On Mon, 13 Mar 2006, Michael J Gruber apparently wrote:=20 > In SVN, the pos argument of deco.arrow() can be anything=20 > between 0 and 1 now (it used be 0 or 1 only). This is in=20 > units of arclength. So, 0.5 is the midpoint, although=20 > I tend use something like 0.55 (pos is where the tip=20 > sits).=20 Thanks! Alan |
From: Joerg L. <jo...@us...> - 2006-03-13 18:17:53
|
Hi Michael! On 13.03.06, Michael J Gruber wrote: > Alan G Isaac venit, vidit, dixit 03/13/06 15:18: > > What's the preferred way to put an arrowhead at the midpoint > > of a line segment? (Like this: http://en.wikipedia.org/wiki/Cobweb_Cycle ) > > Drawing it in two pieces seems the obvious choice right now, > > but it seems like there was talk of a decoration for this? > > > > Thank you, > > Alan Isaac > > I had planned to implement this for a complex analysis script. > Fortunately, I checked the SVN code before to make sure the interface is > still the same. And voila: In SVN, the pos argument of deco.arrow() can > be anything between 0 and 1 now (it used be 0 or 1 only). This is in > units of arclength. So, 0.5 is the midpoint, although I tend use > something like 0.55 (pos is where the tip sits). We should really release soon, there is really too much new stuff in SVN; I even don't remember that this feature has not yet been released. > Thanks, Andre! Hey, all praise and criticism with respect to the arrow code go to me ;-) Jörg |
From: Michael J G. <mic...@fa...> - 2006-03-14 11:56:56
|
Joerg Lehmann venit, vidit, dixit 2006-03-13 19:17: > Hi Michael! ... >> Thanks, Andre! >=20 > Hey, all praise and criticism with respect to the arrow code go to me > ;-) >=20 > J=F6rg The moment I hit "Send" I knew I should have checked the SVN log! So, the new arrow code is fabulous, just what I was about to implement ;) Thanks, J=F6rg! Michael |
From: Gary <pa...@in...> - 2006-03-13 15:34:59
|
Alan G Isaac wrote: >What's the preferred way to put an arrowhead at the midpoint >of a line segment? (Like this: http://en.wikipedia.org/wiki/Cobweb_Cycle ) >Drawing it in two pieces seems the obvious choice right now, >but it seems like there was talk of a decoration for this? > >Thank you, >Alan Isaac > Similar newbie question: How to make a double-ended arrow? ( <--------------------> ) Thanks for you patience, gary |
From: Michael J G. <mic...@fa...> - 2006-03-13 15:55:25
|
Gary venit, vidit, dixit 03/13/06 16:33: > Alan G Isaac wrote: > >> What's the preferred way to put an arrowhead at the midpoint >> of a line segment? (Like this: >> http://en.wikipedia.org/wiki/Cobweb_Cycle ) >> Drawing it in two pieces seems the obvious choice right now, >> but it seems like there was talk of a decoration for this? >> >> Thank you, >> Alan Isaac >> > Similar newbie question: How to make a double-ended arrow? > ( <--------------------> ) For that you don't need the SVN version of PyX, that's in the release code already. The deco module defines the special decorators deco.barrow and deco.earrow for arrows at the begin and end of the path. So, if you want a straight line with double arrows: from pyx import * c = canvas.canvas() c.stroke(path.line(0,0,3,2),[deco.barrow,deco.earrow]) c.writeEPSfile("darrow") The beauty of the underlying concept (decorators) is that you can do this with any paths, not just lines; and that you can add other decorators. You can add text labels simply by adding something like deco.text("label") to the list of decorations. In the current development version you can have multiple arrows at arbitrary positions: [deco.barrow,deco.arrow(0.2),deco.earrow] etc. Cheers, Michael |
From: Alan G I. <ai...@am...> - 2006-03-13 18:39:12
|
On Mon, 13 Mar 2006, Michael J Gruber apparently wrote: > The beauty of the underlying concept (decorators) is that > you can do this with any paths, not just lines Yes, I'm starting to see it! So here is a follow up queston. Suppose I am constructing a path. I reach a point in the construction where the current point is a good location for a decorator to the path. I could use atend to get the coordinates and then do something at the coordinates, basically relying on saving the currentpoint like in PostScript. Is there a way that I can instead save that location in path parameters so that I can later use a decorator? I think this boils down to my current failure to understand the path parameters. I hope my question is nevertheless clear. Thanks, Alan Isaac |
From: Gary <pa...@in...> - 2006-03-13 19:56:49
|
Michael J Gruber wrote: >Gary venit, vidit, dixit 03/13/06 16:33: > > >>Alan G Isaac wrote: >> >> >> >>>What's the preferred way to put an arrowhead at the midpoint >>>of a line segment? (Like this: >>>http://en.wikipedia.org/wiki/Cobweb_Cycle ) >>>Drawing it in two pieces seems the obvious choice right now, >>>but it seems like there was talk of a decoration for this? >>> >>>Thank you, >>>Alan Isaac >>> >>> >>> >>Similar newbie question: How to make a double-ended arrow? >>( <--------------------> ) >> >> > >For that you don't need the SVN version of PyX, that's in the release >code already. The deco module defines the special decorators deco.barrow >and deco.earrow for arrows at the begin and end of the path. So, if you >want a straight line with double arrows: > >from pyx import * >c = canvas.canvas() >c.stroke(path.line(0,0,3,2),[deco.barrow,deco.earrow]) >c.writeEPSfile("darrow") > >The beauty of the underlying concept (decorators) is that you can do >this with any paths, not just lines; and that you can add other >decorators. You can add text labels simply by adding something like >deco.text("label") to the list of decorations. > Thanks for the reply. BTW, this is my second time around trying to learn PyX. The first time I tried something too ambitious, and got very confused. Learning PyX seems to require a slow period of osmosis. But consider this: from pyx import * c = canvas.canvas() c.stroke(path.line(0,0,3,2),[deco.barrow,deco.earrow, deco.text("hello")]) c.writeEPSfile("darrow") Traceback (most recent call last): File "<stdin>", line 3, in ? AttributeError: 'module' object has no attribute 'text' deco does not have a method or attribute called "text". Did you have something different in mind? -gary >In the current >development version you can have multiple arrows at arbitrary positions: >[deco.barrow,deco.arrow(0.2),deco.earrow] etc. > >Cheers, >Michael > > > |
From: Joerg L. <jo...@us...> - 2006-03-13 21:24:09
|
Hi Gary, On 13.03.06, Gary wrote: > Thanks for the reply. BTW, this is my second time around trying to learn > PyX. The first time I tried something too ambitious, and got very > confused. Learning PyX seems to require a slow period of osmosis. I understand this, but on the other hand you also get a rather powerful system as a reward. > But consider this: > > from pyx import * > c = canvas.canvas() > c.stroke(path.line(0,0,3,2),[deco.barrow,deco.earrow, deco.text("hello")]) > c.writeEPSfile("darrow") > > Traceback (most recent call last): > File "<stdin>", line 3, in ? > AttributeError: 'module' object has no attribute 'text' > > deco does not have a method or attribute called "text". Did you have > something different in mind? The text decorator is just present in the SVN version, i.e., it's not yet released. Oh well, see my previous mail somewhere in this thread; we're strongly violating the release earlier, release often paradigm. But I suppose that's what happens if time is a scarce resource. Jörg |
From: Gary <pa...@in...> - 2006-03-14 18:34:49
|
I've looked at the example connect.py, and the docs. The way I understand it, the bbox() method of a path will return a bbox. The connector.arc method takes two bbox arguments. It looks like connect.py works that way. Then why does the following fail? from pyx import * c = canvas.canvas() l1 = path.line(0,0,3,2) c.stroke(l1) l2 = path.line(5,5,6,6) c.stroke(l2) b1 = l1.bbox() b2 = l2.bbox() c.stroke(b1.path()) c.stroke(b2.path()) c.stroke(connector.arc(b1,b2)) c.writeEPSfile("testconnect") Traceback (most recent call last): File "<stdin>", line 17, in ? File "c:\python24\Lib\site-packages\pyx\connector.py", line 390, in __init__ boxdists=boxdists_pt) File "c:\python24\Lib\site-packages\pyx\connector.py", line 117, in __init__ rel = (self.box2.center[0] - self.box1.center[0], TypeError: unsubscriptable object I notice that a text instance is itself a "text.textbox", while a path is a "path.line". the bbox() method on either a text.textbox or a path.line returns a "bbox.box_pt". It seems that connector.arc will accept a text.textbox argument, but not a bbox.box_pt arg. In any event, it seems that either bbox() does not really return a bbox, or connect.arc really does not take a bbox. Or both. What's going on? -gary |
From: Gary <pa...@in...> - 2006-03-14 23:51:55
|
Gary wrote: > I've looked at the example connect.py, and the docs. The way I > understand it, the bbox() method of a path will return a bbox. The > connector.arc method takes two bbox arguments. It looks like > connect.py works that way. > Then why does the following fail? > > from pyx import * > c = canvas.canvas() > l1 = path.line(0,0,3,2) > c.stroke(l1) > l2 = path.line(5,5,6,6) > c.stroke(l2) > b1 = l1.bbox() > b2 = l2.bbox() > c.stroke(b1.path()) > c.stroke(b2.path()) > c.stroke(connector.arc(b1,b2)) > c.writeEPSfile("testconnect") > > Traceback (most recent call last): > File "<stdin>", line 17, in ? > File "c:\python24\Lib\site-packages\pyx\connector.py", line 390, in > __init__ > boxdists=boxdists_pt) > File "c:\python24\Lib\site-packages\pyx\connector.py", line 117, in > __init__ > rel = (self.box2.center[0] - self.box1.center[0], > TypeError: unsubscriptable object > > I notice that a text instance is itself a "text.textbox", while a path > is a "path.line". > the bbox() method on either a text.textbox or a path.line returns a > "bbox.box_pt". > > It seems that connector.arc will accept a text.textbox argument, but > not a bbox.box_pt arg. > > In any event, it seems that either bbox() does not really return a > bbox, or connect.arc really does not take a bbox. Or both. > > What's going on? > > -gary It looks like text.text.(0,0, 'hello').center is a tuple attribute, but path.line(0,0,1,1).bbox().center is a method ... and connector chokes on it. Are there two types of box? Is it possible to convert a path-style bbox into the kind of box that connector wants? -gary |
From: Michael S. <m-s...@us...> - 2006-03-15 13:32:12
|
Hello Gary, On 14.03.06, Gary wrote: > >I've looked at the example connect.py, and the docs. The way I > >understand it, the bbox() method of a path will return a bbox. The > >connector.arc method takes two bbox arguments. It looks like > >connect.py works that way. > >Then why does the following fail? > > > >from pyx import * > >c = canvas.canvas() > >l1 = path.line(0,0,3,2) > >c.stroke(l1) > >l2 = path.line(5,5,6,6) > >c.stroke(l2) > >b1 = l1.bbox() > >b2 = l2.bbox() > >c.stroke(b1.path()) > >c.stroke(b2.path()) > >c.stroke(connector.arc(b1,b2)) > >c.writeEPSfile("testconnect") > > > >In any event, it seems that either bbox() does not really return a > >bbox, or connect.arc really does not take a bbox. Or both. > > > >What's going on? > > > >-gary > > It looks like text.text.(0,0, 'hello').center is a tuple attribute, but > path.line(0,0,1,1).bbox().center is a method ... and connector chokes on it. > Are there two types of box? Yes. One is the bbox, which is a "bounding box", always a rectangle, consisting of horizontal and vertical lines. The other is a box, that is a container with a center and an outline path, which is at the moment restricted to convex piecewise straight lines. boxes are a major design element for the (near) future of PyX. They should align automatically to each other, should be enlarged etc. At the moment they do the alignment of axis-labels in graphs. For connectors, it seemed natural to take the boxes as arguments. > Is it possible to convert a path-style bbox > into the kind of box that connector wants? Sure. You initialise it with the coordinates from the bbox. bb = (some bbox) b = box.rect(bb.left(), bb.bottom(), bb.width(), bb.height()) and that's it Michael. P.S: Please be aware that the angle parameterisation of the connectors changed from 0.8.1 to the current svn version. If you are using the svn please consult the manual there. -- "A mathematician is a device for turning coffee into theorems" Paul Erdös. |
From: Gary <pa...@in...> - 2006-03-15 16:04:33
|
Michael Schindler wrote: >Hello Gary, > >On 14.03.06, Gary wrote: > > >>>I've looked at the example connect.py, and the docs. The way I >>>understand it, the bbox() method of a path will return a bbox. The >>>connector.arc method takes two bbox arguments. It looks like >>>connect.py works that way. >>>Then why does the following fail? >>> >>> >>> >>>from pyx import * >> >> >>>c = canvas.canvas() >>>l1 = path.line(0,0,3,2) >>>c.stroke(l1) >>>l2 = path.line(5,5,6,6) >>>c.stroke(l2) >>>b1 = l1.bbox() >>>b2 = l2.bbox() >>>c.stroke(b1.path()) >>>c.stroke(b2.path()) >>>c.stroke(connector.arc(b1,b2)) >>>c.writeEPSfile("testconnect") >>> >>>In any event, it seems that either bbox() does not really return a >>>bbox, or connect.arc really does not take a bbox. Or both. >>> >>>What's going on? >>> >>>-gary >>> >>> >>It looks like text.text.(0,0, 'hello').center is a tuple attribute, but >>path.line(0,0,1,1).bbox().center is a method ... and connector chokes on it. >> >> > > > >>Are there two types of box? >> >> > >Yes. One is the bbox, which is a "bounding box", always a rectangle, >consisting of horizontal and vertical lines. The other is a box, that >is a container with a center and an outline path, which is at the >moment restricted to convex piecewise straight lines. boxes are a >major design element for the (near) future of PyX. They should align >automatically to each other, should be enlarged etc. At the moment >they do the alignment of axis-labels in graphs. > >For connectors, it seemed natural to take the boxes as arguments. > > I must be blind. It's only now that I see the section in the docs about the box module. And the chapter on connectors clearly says "box" and not "bbox". My brain must have refused to see the difference between box and bbox. Thanks for your patient reply. > > >>Is it possible to convert a path-style bbox >>into the kind of box that connector wants? >> >> > >Sure. You initialise it with the coordinates from the bbox. > > bb = (some bbox) > b = box.rect(bb.left(), bb.bottom(), bb.width(), bb.height()) > >and that's it > > OK. I'm catching on slowly. -gary >Michael. > >P.S: Please be aware that the angle parameterisation of the connectors >changed from 0.8.1 to the current svn version. If you are using the >svn please consult the manual there. > > > |
From: Alan G I. <ai...@am...> - 2006-03-13 18:16:37
|
On Mon, 13 Mar 2006, Gary apparently wrote:=20 > How to make a double-ended arrow? =20 The arrow decorators aren't exclusive. Just decorate both ends: mypath.stroke(arrow,[pyx.deco.arrow([pyx.color.rgb.blue],position=3D0), pyx.deco.arrow([pyx.color.rgb.red],position=3D1)] ) hth, Alan Isaac |