From: Armin S. <li...@ar...> - 2005-09-21 09:51:35
Attachments:
xcanvas.py
|
Hi, when writing the point() function for SimplyDraw, I reused functions like pyx.graph.style._circlesymbol from the graph styles. I'm not really satisfied with my type=dot parameter, because I think it would be more PyX like to handle the type via an attr perhaps named symbol. To fix ideas I therefore wrote this symbol attribute (I have attached the file where it is defined). Using this for a new implementation of canvas.point() one would be able to do e.g. point(x, y) point(x, y, symbol.cross) point(x, y, symbol.dot([rbg.red])) point(x, y, symbol.plus(size=.3)). I have never written an attribute class before, so I might have mixed some things. Nevertheless I hope that the new point() function behaves more PyXic ;) Now I wonder if such an attribute could have more usage as just in the point() function. One idea could be a path decorator that places symbols at the edges of a path. Unfortunately I didn't see an easy way for getting the vertices of a path as the points supplied e.g. to lineto seem not to get stored for retrieval. Cheers -- Armin Straub |
From: Joerg L. <jo...@us...> - 2005-09-21 11:25:37
|
Hi Armin, On 21.09.05, Armin Straub wrote: > when writing the point() function for SimplyDraw, I reused functions like > pyx.graph.style._circlesymbol from the graph styles. Fair enough, but the PyX support for things like this could be better. > I'm not really satisfied > with my type=dot parameter, because I think it would be more PyX like to > handle the type via an attr perhaps named symbol. > > To fix ideas I therefore wrote this symbol attribute (I have attached the file > where it is defined). Using this for a new implementation of canvas.point() > one would be able to do e.g. > point(x, y) > point(x, y, symbol.cross) > point(x, y, symbol.dot([rbg.red])) > point(x, y, symbol.plus(size=.3)). > I have never written an attribute class before, so I might have mixed some > things. Nevertheless I hope that the new point() function behaves more > PyXic ;) Note that usually in PyX, attributes come in lists, so the PyX-way of doing this would be point(x, y, [symbol.cross]) Then you could also allow things like point(x, y, [color.rgb.red, symbol.cross]) > Now I wonder if such an attribute could have more usage as just in the point() > function. One idea could be a path decorator that places symbols at the edges > of a path. Unfortunately I didn't see an easy way for getting the vertices of > a path as the points supplied e.g. to lineto seem not to get stored for > retrieval. They are stored as attributes x_pt and y_pt, that is, in PS points. However, "edges of a path" may not be a very well defined concept. I could imagine something like the first and last point of a line and the first and last points of a Bézier curve. If you want to use that, just convert the path in a normpath and use that instead. But your idea is still interesting. We could have something like: c.stroke(path.point(x, y), [deco.symbol.cross]) where point is a degenerate line: class point(line): def __init__(x, y): line.__init__(x, y, x, y) The advantage would be that one decouples the position x, y from the rest of the symbol. One would have to think about the implications when stroking/filling such an object, though. An alternative solution without this problem would be to put the symbol in the path (future: paths) module and have something like c.stroke(path.cross(x, y, size=3), [color.rgb.red]) Then, the separation between the position and the rest of the attributes is drawn differently. Of course, we could also have a combination between both ways, with the second way (via path(s)) being the more fundamental one. Jörg |
From: Armin S. <li...@ar...> - 2005-09-21 16:48:44
|
Hallo, > Note that usually in PyX, attributes come in lists, so the PyX-way of > doing this would be > > point(x, y, [symbol.cross]) > > Then you could also allow things like > > point(x, y, [color.rgb.red, symbol.cross]) This was really what my first attempt looked like, but then I thought that= =20 e.g. the color should be an attribute of the symbol. What I had in mind was= =20 the idea of using symbol in other places, too, e.g. line(x1, y1, x2, y2, [rgb.red, symbol.cross([rgb.blue])]). Just taking the symbol as a parameter and not a list of attributes is model= led=20 after the usage of the style parameter in plot(). I defined symbol as an=20 attribute (in contrast to a graph style) though, because of possible future= =20 usecases. > They are stored as attributes x_pt and y_pt, that is, in PS points. Ah, so I can access e.g. the vertices of a rect via the pathitems and x_pt,= =20 y_pt. Nice to know. Thanks! > However, "edges of a path" may not be a very well defined concept. I > could imagine something like the first and last point of a line and the > first and last points of a B=E9zier curve. If you want to use that, just > convert the path in a normpath and use that instead. I'm sorry. s/edges/vertices/. I missed this one. The idea was to have a=20 decorator that could emphasize e.g. the vertices of a triangle. > But your idea is still interesting. We could have something like: > > c.stroke(path.point(x, y), [deco.symbol.cross]) > > where point is a degenerate line: > > class point(line): > def __init__(x, y): > line.__init__(x, y, x, y) > > The advantage would be that one decouples the position x, y from the > rest of the symbol. One would have to think about the implications when > stroking/filling such an object, though. I like this idea. And it would fit into the concept of symbol.cross drawing= a=20 cross at each vertex of a general path. > An alternative solution without this problem would be to put the symbol > in the path (future: paths) module and have something like > > c.stroke(path.cross(x, y, size=3D3), [color.rgb.red]) > > Then, the separation between the position and the rest of the attributes > is drawn differently. > > Of course, we could also have a combination between both ways, with the > second way (via path(s)) being the more fundamental one. I don't know if a path.cross or a path.diamond would be of much use besides= =20 representing a point. But it may be worth some thoughts... Cheers =2D-=20 Armin Straub |
From: Joerg L. <jo...@us...> - 2005-09-21 17:10:01
|
Hi, On 21.09.05, Armin Straub wrote: > > Note that usually in PyX, attributes come in lists, so the PyX-way of > > doing this would be > > > > point(x, y, [symbol.cross]) > > > > Then you could also allow things like > > > > point(x, y, [color.rgb.red, symbol.cross]) > > This was really what my first attempt looked like, but then I thought that > e.g. the color should be an attribute of the symbol. What I had in mind was > the idea of using symbol in other places, too, e.g. > line(x1, y1, x2, y2, [rgb.red, symbol.cross([rgb.blue])]). Ok, but here you still have a list. So why should it be different for a point? > Just taking the symbol as a parameter and not a list of attributes is modelled > after the usage of the style parameter in plot(). Since PyX 0.7 at least, plot expects a list of styles. > I defined symbol as an > attribute (in contrast to a graph style) though, because of possible future > usecases. Yes, that's the point. [ snip ] > > However, "edges of a path" may not be a very well defined concept. I > > could imagine something like the first and last point of a line and the > > first and last points of a Bézier curve. If you want to use that, just > > convert the path in a normpath and use that instead. > > I'm sorry. s/edges/vertices/. I missed this one. The idea was to have a > decorator that could emphasize e.g. the vertices of a triangle. But what about a circle or an arc, for instance? And Bezier curves? > > But your idea is still interesting. We could have something like: > > > > c.stroke(path.point(x, y), [deco.symbol.cross]) > > > > where point is a degenerate line: > > > > class point(line): > > def __init__(x, y): > > line.__init__(x, y, x, y) > > > > The advantage would be that one decouples the position x, y from the > > rest of the symbol. One would have to think about the implications when > > stroking/filling such an object, though. > > I like this idea. And it would fit into the concept of symbol.cross drawing a > cross at each vertex of a general path. Right. At least, if we get the semantics of such a thing right. > > An alternative solution without this problem would be to put the symbol > > in the path (future: paths) module and have something like > > > > c.stroke(path.cross(x, y, size=3), [color.rgb.red]) > > > > Then, the separation between the position and the rest of the attributes > > is drawn differently. > > > > Of course, we could also have a combination between both ways, with the > > second way (via path(s)) being the more fundamental one. > > I don't know if a path.cross or a path.diamond would be of much use besides > representing a point. But it may be worth some thoughts... It would just serve as a common basis for various users (both internally in PyX and also as an external interface) of such a symbol. This fits very well with a recent discussion we had concerning the connectors. The basic implementation could be in a new paths module with a version which is more specialized for the (original) use of connecting boxes then being based on this low-level interface. Jörg |
From: Armin S. <li...@ar...> - 2005-09-22 07:26:31
|
Hallo, > This was really what my first attempt looked like, but then I thought that > e.g. the color should be an attribute of the symbol. What I had in mind w= as > the idea of using symbol in other places, too, e.g. > =A0 line(x1, y1, x2, y2, [rgb.red, symbol.cross([rgb.blue])]). > Just taking the symbol as a parameter and not a list of attributes is > modelled after the usage of the style parameter in plot(). I defined symb= ol > as an attribute (in contrast to a graph style) though, because of possible > future usecases. I'm sorry for my confusion. Of course there is no style parameter for plot(= )=20 but styles. Nonetheless usage of symbol is modelled after the usage of e.g.= =20 style.line(). The reason for not taking a list of attributes is that there are no others= =20 besides symbol here, which may be of use. Cheers =2D-=20 Armin Straub |
From: Andre W. <wo...@us...> - 2005-09-22 13:24:23
|
Hi, On 21.09.05, Armin Straub wrote: > > This was really what my first attempt looked like, but then I thought that > > e.g. the color should be an attribute of the symbol. What I had in mind was > > the idea of using symbol in other places, too, e.g. > > line(x1, y1, x2, y2, [rgb.red, symbol.cross([rgb.blue])]). > > Just taking the symbol as a parameter and not a list of attributes is > > modelled after the usage of the style parameter in plot(). I defined symbol > > as an attribute (in contrast to a graph style) though, because of possible > > future usecases. > > I'm sorry for my confusion. Of course there is no style parameter for plot() > but styles. Nonetheless usage of symbol is modelled after the usage of e.g. > style.line(). > The reason for not taking a list of attributes is that there are no others > besides symbol here, which may be of use. Well, I remember some discussion about removing the symbol graph style completely in favour of decorating a line. In principle you could stroke those symbols by a decorator. I've added a very preliminary shownormpath decorator recently (today actually IIRC), which does something like that, although I had the different use-case in mind, namely to have a handy decorator showing some details of a path. However, in the discussion we had we decided to not to do that. There are several points why it's not a good idea. Let me try to remember those points. - We wanted the line and the symbol style to be symmetric in it's use. Maybe we should throw this feature away, but it's worth to remember. - We do get into troubles at the graph boundary, where a line is cut, but we would not have to stroke a symbol. - There are cases, where no line is inserted into a graph, although single points exists, since the data might contain undefined points. Of course there's no line drawn for those undefined points and currently even a single defined point between undefined points is thrown away (not even a moveto is inserted for such a point). Still, we might think of building more decorators and using them at various places, for example at the symbol style. The symbol style already is very tiny and why not doing it differently, namely construct a path containing only moveto's and use a symbol decorator on that path. It's at least worth a discussion. Recently we also had the discussion about the axis painters, which are, in some sense, also decorators (or a combination of decorators). One should have in mind, that all those constructions are older than the decorators, but in the future we might want to change that in favour of decorators. To be discussed ... case by case. So what about the symbols? André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Andre W. <wo...@us...> - 2005-09-22 13:10:48
|
Hi, On 21.09.05, Armin Straub wrote: > Now I wonder if such an attribute could have more usage as just in the point() > function. One idea could be a path decorator that places symbols at the edges > of a path. Unfortunately I didn't see an easy way for getting the vertices of > a path as the points supplied e.g. to lineto seem not to get stored for > retrieval. I'm not sure whether the other discussion had well covered this point. That's what normpaths are for. Those contain subnormpaths which contain subnormpathitems, which are either normline_pt or normcurve_pt instances. By that we can do all the numerics on the paths. Whenever you need to analyse a path you should use normpaths, which make live much easier. Especially since they are context-free. A rlineto pathitem for example doesn't even tell you the end point of this path segment. The only way to achive this information is to analyse the path items in their proper context. Beside that there's a bunch of similar path items, just because we decided to reproduce the full postscript path system. OTOH, when analysing a path, the normpath is almost always the way to go ... André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |