On 23.07.04, Magnus Lie Hetland wrote:
> [...] It seems to me that
> having a point type (class) would be useful (I'm used to the MetaPost
> way ;) but I guess maybe there is a way of doing this gracefully in
> Pyx as well...
As we started PyX we decided to not introduce a point data type in
order to lower the users overhead. Thus you directly use plain numbers
(or a PyX length) at various places like in path.moveto() or
text.text() instead of first constructing points. We not even started
to group together coordinates in tuples (you could think of
path.line((x1, y1), (x2, y2)), but we actually decided to use
path.line(x1, y1, x2, y2)). So we do not have a proper representation
of a point.
A path, however, is a pure mathematical object. Especially the
normpath (any path can converted to) supports quite some numerical
operations (splitting, calcuation of intersection points, etc.).
Futhermore the (affine) transformations are mathematical objects.
While they also support the transformation of a point by the apply
method didn't we introduce a point class here either.
> Should I fiddle with the numbers directly? Use a path element? Perhaps
> gather the points in a path? Use boxes with zero extent? What's the
> 'Pyx Way' here?
As I said, I think none of the existing classes should be (miss-)used
for your needs. They all do not fit well. A path element is a path
element, not a point. Sometimes it might be usefull as a return value,
but it still is not a point. You might build up a path, when you want
to construct a path in the end, but its not the correct representation
of a list of points, because a path also defines, what's "in between"
the points. The boxes are something very different (at least I think
we'll move them towards the following): A box is an ordinary canvas
having a predefined boundary. In the end, boxes will be the primary
source for performing clipping operations. Of course, the aligment
functionality will be usefull for objects with any kind of border as
it is today already for the boxes we have. The connector functionality
might become less restricted to boxes in the future. We'll see.
So, in the end, we might think about introducing a point class and
numerics on points. Especially when we want create some features found
in MetaPost. I'm quite open to this discussion. I was asked about
MetaPost like features several times already. I'm also willing to
spend time on developing the fundamentals, but I think we should start
with independend classes in the first. Later on it might become clear,
that one should integrate the point class etc. more directly into PyX
(i.e. add support into the path class etc.). A related question might
be, if the point class (and related things) should support PyX
lengths. In favor of PyX I think one should try to do so ...
by _ _ _ Dr. André Wobst
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX
(_/ \_)_/\_/ visit http://pyx.sourceforge.net/