From: Otto T. <zz...@ma...> - 2003-10-20 14:34:55
Attachments:
normdist.diff
dotted-test.py
|
Hi, I just recently discovered PyX and I must say that it looks really promising. Especially you got one really important thing right that most (if any) other packages fail with, namely you use (La)TeX for typesetting the text. And that is number one reason for me to try out PyX. However, I have found one thing that I miss. The length of dashes and space in dashed, dotted, and dashdotted is absolute and not relative to line width. So if I draw a THICK dotted line I get a semi solid line instead. Therefore, I propose to add the possibility to define the dashes in terms of the current line width, something like the attached patch. It does the following: 1: The init function of dashes takes an additional argument normdist. If it is set to true it emitts code like [0 currentlinewidth mul 3 currentlinewidth mul ] 0 setdash instead of [0 3 ] 0 setdash BTW: What version of python do you require? Is it ok to use True and False instead? 2: However, for this to work the linewidth must be set before we set the dash so I introduced a class member in PathStyle named prio (default 0) and I set this prio to 1 in linewidth. Then in decoratedpath::_writestyles I do a reverse sort on prio before we write the styles to file. 3: I wasn't sure if it should be default behavior so I introduced dottedn, dashedn, and dashdottedn for now. I don't know if this takes care of all cases for dashed lines (can I draw a dashed line without decoratedpath?) However, it works for the attached test case (dotted-test.py) so it is at least a proof of concept. What do you think, is this a wanted feature? /Otto |
From: Joerg L. <jo...@us...> - 2003-10-21 12:11:22
|
Hi Otto, On 20.10.03, Otto Tronarp wrote: > However, I have found one thing that I miss. The length of dashes and > space in dashed, dotted, and dashdotted is absolute and not relative > to line width. So if I draw a THICK dotted line I get a semi solid > line instead. Therefore, I propose to add the possibility to define > the dashes in terms of the current line width, something like the > attached patch. > > It does the following: > > 1: The init function of dashes takes an additional argument > normdist. If it is set to true it emitts code like > [0 currentlinewidth mul 3 currentlinewidth mul ] 0 setdash > instead of > [0 3 ] 0 setdash I could swear that I once - some years ago - tried using noninteger numbers in the array passed to the setdash operator - and it didn result in an error. So my first thought was that your solution doesn't work at all. But, of course, you're right and in principle, we could do that. However, I don't like the name normdist too much. It doesn't seem to be very intuitive, does it? How about one of the following. - absolute - abslengths - abslen - relative - rellengths - rellen Further suggestions? > BTW: What version of python do you require? Is it ok to use True and > False instead? At the moment we only require Python 2.1, because it is the default in Debian/stable, which does not know True and False. > 2: However, for this to work the linewidth must be set before we set > the dash so I introduced a class member in PathStyle named prio > (default 0) and I set this prio to 1 in linewidth. Then in > decoratedpath::_writestyles I do a reverse sort on prio before we > write the styles to file. Similar ordering problems arise at other places in PyX, where we use a similar solution. André, maybe we should use the mechanism of the text module? > 3: I wasn't sure if it should be default behavior so I > introduced dottedn, dashedn, and dashdottedn for now. I really want to avoid the duplication of linestyles, so one should really choose a sensible default. I would tend to use the "automatic" behaviour. Other options? > I don't know if this takes care of all cases for dashed lines (can I > draw a dashed line without decoratedpath?) However, it works for the > attached test case (dotted-test.py) so it is at least a proof of concept. In principle you can draw a dashed line without decoratedpath but this is neither the recommended behaviour nor is it documented. So your solution is fine. Jörg -- JOERG LEHMANN | PyX - High quality PostScript figures with Python & TeX jo...@lu... | Visit http://pyx.sourceforge.net/ |
From: Andre W. <wo...@us...> - 2003-10-21 23:52:31
|
Hi, On 21.10.03, Joerg Lehmann wrote: > > 2: However, for this to work the linewidth must be set before we set > > the dash so I introduced a class member in PathStyle named prio > > (default 0) and I set this prio to 1 in linewidth. Then in > > decoratedpath::_writestyles I do a reverse sort on prio before we > > write the styles to file. > > Similar ordering problems arise at other places in PyX, where we > use a similar solution. André, maybe we should use the mechanism > of the text module? Well, I'm not satisfied with the attribute handling (expecially its ordering) in the text module since it uses magic numbers. I'm still not sure what to do regarding this subject. For the moment, a magic sorting is the best we can do, but we should try to think hard for a generic solution for the future. André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us... / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Otto T. <zz...@ma...> - 2003-10-22 06:57:16
|
Hi Joerg, On Tue, 2003-10-21 at 14:06, Joerg Lehmann wrote: > Hi Otto, > > However, I don't like the name normdist too much. It doesn't seem > to be very intuitive, does it? How about one of the following. > > - absolute > - abslengths > - abslen > - relative > - rellengths > - rellen >=20 > Further suggestions? >=20 I admit that my choice wasn't the best. I think that the name should communicate that it is a length so that leaves *len and *lengths. When it comes to absolute vs. relative I think that relative is more suitable. So if I have a vote I would vote for rellengths or rellen (or even relativelen). I can prepare a new patch when you guys reaches a decision on the name issue. > > BTW: What version of python do you require? Is it ok to use True and > > False instead? >=20 > At the moment we only require Python 2.1, because it is the default in > Debian/stable, which does not know True and False. >=20 > > 2: However, for this to work the linewidth must be set before we set > > the dash so I introduced a class member in PathStyle named prio > > (default 0) and I set this prio to 1 in linewidth. Then in > > decoratedpath::_writestyles I do a reverse sort on prio before we > > write the styles to file. >=20 > Similar ordering problems arise at other places in PyX, where we > use a similar solution. Andr=E9, maybe we should use the mechanism > of the text module? >=20 I took a quick look and it seems that it only differs on some minor points. * texsettings uses id instead of prio * texsettings defines a __cmp__ in the base class instead of supplying =20 sort with a custom compare function Besides that it also defines a class member exclusive and only one object with the same id is allowed if the exclusive flag is set. I don't know if the last thing is applicable to pathstyles, but I can prepare a new patch with id instead of prio and that defines a __cmp__. What do you think? > > 3: I wasn't sure if it should be default behavior so I > > introduced dottedn, dashedn, and dashdottedn for now. >=20 > I really want to avoid the duplication of linestyles, so one > should really choose a sensible default. I would tend to > use the "automatic" behaviour. Other options? >=20 So do I, but the default values might need some tweaking. A general question: What is all those __implements__ about, I couldn't find anything that uses them in the source tree. So I thought that it was some feature in python, but I couldn't find anything in the documentation. /Otto |
From: Andre W. <wo...@us...> - 2003-10-22 11:53:43
|
Hi Otto, On 21.10.03, Otto Tronarp wrote: > I admit that my choice wasn't the best. I think that the name should > communicate that it is a length so that leaves *len and *lengths. When > it comes to absolute vs. relative I think that relative is more > suitable. So if I have a vote I would vote for rellengths or rellen (or > even relativelen). > > I can prepare a new patch when you guys reaches a decision on the name > issue. If you spend a look to the new connector module by Michael Schindler, the matching name would be rellengths ... > > > BTW: What version of python do you require? Is it ok to use True and > > > False instead? > > > > At the moment we only require Python 2.1, because it is the default in > > Debian/stable, which does not know True and False. > > > > > 2: However, for this to work the linewidth must be set before we set > > > the dash so I introduced a class member in PathStyle named prio > > > (default 0) and I set this prio to 1 in linewidth. Then in > > > decoratedpath::_writestyles I do a reverse sort on prio before we > > > write the styles to file. > > > > Similar ordering problems arise at other places in PyX, where we > > use a similar solution. André, maybe we should use the mechanism > > of the text module? > > > > I took a quick look and it seems that it only differs on some minor > points. > * texsettings uses id instead of prio > * texsettings defines a __cmp__ in the base class instead of supplying > sort with a custom compare function > Besides that it also defines a class member exclusive and only one > object with the same id is allowed if the exclusive flag is set. Exactly. I should tell you that there is a long standing discussion about attributes used in methods like canvas.stroke, canvas.fill, canvas.text and at a few other places. There is no common style in terms of those attributes. We already thought about building a generic interface in a new attrib-module (should become a directory with modules like strokeattr, fillattr, textattr, color, ...) where things like sorting, excluding, merging etc. should be implemented once and for all. It would be nice to even include changeable attributes (the graph has something like that right now, but I consider it a dirty hack although I've written this specific crap myself), specialization of attributes (I don't like the special way of arrows having a __call__ method although we might come up with a solution using __call__). One idea is to get rid of the problem, that you can not easily change some default attributes provided in keyword arguments. Suppose write some function: def StrokeRedPathWithBlueText(c, p, t, # canvas, path, and text pathattrs=[color.rgb.red], textattrs=[color.rgb.blue]): c.stroke(p, *pathattrs) c.text(0, 0, t, *textattrs) You now want stroke the path thick. You can't without repeating the attribute color.rgb.red. That's bad. On the other hand you want to be able to remove some default attributes (if you force a removal). And you want some exclusion of some attributes, some sorting etc. > I don't know if the last thing is applicable to pathstyles, but I can > prepare a new patch with id instead of prio and that defines a __cmp__. > What do you think? Hmmm. I'm not sure. I think it doesn't really matter for the moment and it is not worth the trouble to implement something very complicated while we still have to come up with a solution on the topic I discussed above (instead you may have some thoughts regarding this subject as a hole). > A general question: What is all those __implements__ about, I couldn't > find anything that uses them in the source tree. So I thought that it > was some feature in python, but I couldn't find anything in the > documentation. No, it is not a python language feature, but a coding style feature. We use it for documentation purposes only, while some other projects (cf. zope3) might use it for further code analysis and documentation. André -- by _ _ _ Dr. André Wobst / \ \ / ) wo...@us... / _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX (_/ \_)_/\_/ visit http://pyx.sourceforge.net/ |
From: Otto T. <zz...@ma...> - 2003-11-19 17:46:25
Attachments:
rellengths.diff
|
Sorry for the late reply. On Tue, 2003-10-21 at 14:06, Joerg Lehmann wrote: > However, I don't like the name normdist too much. It doesn't seem > to be very intuitive, does it? How about one of the following. Fixed in the attached patch (I used rellengths as suggested by Andr=E9) > Similar ordering problems arise at other places in PyX, where we > use a similar solution. Andr=E9, maybe we should use the mechanism > of the text module? >=20 =20 In the attached patch I use a __cmp__ function instead of supplying sort with a custom compare function. (As in the text module) > I really want to avoid the duplication of linestyles, so one > should really choose a sensible default. I would tend to > use the "automatic" behaviour. Other options? >=20 Fixed in the attached. /Otto |
From: Joerg L. <jo...@us...> - 2003-11-20 09:39:54
|
Hello Otto, On 19.11.03, Otto Tronarp wrote: > Sorry for the late reply. No problem. However, in the meantime, we have (partially) implemented an attribute system as outlined by André in a previous mail in this thread. > On Tue, 2003-10-21 at 14:06, Joerg Lehmann wrote: > > However, I don't like the name normdist too much. It doesn't seem > > to be very intuitive, does it? How about one of the following. > > Fixed in the attached patch (I used rellengths as suggested by André) Ok. > > Similar ordering problems arise at other places in PyX, where we > > use a similar solution. André, maybe we should use the mechanism > > of the text module? > > > > In the attached patch I use a __cmp__ function instead of supplying sort > with a custom compare function. (As in the text module) Dependency of attributes can now be specified more generally with the new attribute system. In particular, we already took care of the linestyle vs. linewidth sort order. > > I really want to avoid the duplication of linestyles, so one > > should really choose a sensible default. I would tend to > > use the "automatic" behaviour. Other options? We discussed this internally some weeks ago and in the end, it came to the conclusion that probably the old way should be the default. Gert, could you comment on this? Jörg |