pyx-devel — PyX development

[PyX-devel] Announcement: PyX 0.6 released

[Andre W. <wo...@us...>]

Hi,

we are proud to announce the release of PyX 0.6. This release further
improves the internal design and visible interfaces of PyX. The path
system has undergone a major revision and cleanup. The graph module
has been split into several smaller modules reflecting its component
architecture. Moreover, it now makes use of the attribute system
introduced in the previous release. Graph styles and data handling
have been largely revised. Major parts of the documentation have been
rewritten and are now based on the standard Python documentation
style. Bug-fixes and speed improvements complete this release.

Find a more detailed list of changes below. Enjoy!


Jörg, Michael, André


----------

0.6 (2004/03/30):
  - graph module:
    - reorganisation of the graph structure finished (there might be some
      small pending issues, but the basic restructuring is done with this release):
      - graph splitted into several modules in pyx/graph and pyx/graph/axis
      - painters are using the new attribute scheme including changeable
        attributes
      - graph styles rewrite
      - graph data rewrite
    - axis zeropath feature has been removed
    - mergelabels removed; linpart doesn't have a label argument anymore
    - names and texts removed from baraxis
    - iteration on graph style, when it is used several times in the same graph
    - symbols + lines -> symbollines; symbols do not allow setting lineattrs,
      and lines not symbolattrs
    - manual line clipping (do not include unneeded line segments when the
      axis range is set manually etc.)
    - automatic file key titles
    - graph.data now also includes the old data module
    - data.list adds (by default) a line number like data.file
      (thus regular columns are counted from 1)
  - path:
    - added new pathels multilineto_pt and multicurveto which allows to specify
      a list of points and can thus be much more efficient
    - internal methods return coordinates in pts
    - arclentoparam returns only parameters not total length
    - added path.arclength_pt, path.at_pt, path.begin_pt, path.end_pt (and
      correspondingly for normpath)
    - complete refactoring of the normpath class: normpaths now consist of
      normsubpaths which themselves consist of normlines and normcurves This is
      much more convenient for any routines working with normpaths.
    - reversing of closed sub paths does not change the first point of the sub
      path
    - renamed: arclength -> arclen
    - renamed: lentopar -> arclentoparam
    - renamed: glue -> joined
    - normpath now supports join, the in-place version of joined
    - path and normpath method raise exception instead of returning None
      when parameter is out of range
    - the accuracy epsilon can now only be specified in normpath and normsubpath
      constructor and no longer in arguments of path and normpath methods
    - negative parameters are no longer supported in path and normpath methods
    - path and normpath methods which accept parameter value param now
      alternatively accept an arc length
  - deco module:
    - cycloid decorator
    - smoothed decorator
    - arrow heads are no longer stroked (as suggested by Magnus Lie Hetland)
  - canvas:
    - writeEPSfile deprecates writetofile
    - internally, write methods are renamed in outputPS
    - canvas constructor no longer accepts variable argument list but
      expects a list of attrs as first argument (defaulting to []) and
      a texrunner as second argument (defaulting to text.defaulttexrunner)
    - set, draw, stroke and fill no longer return self, i.e., the canvas, but None
  - bbox module:
     - added inplace add (__iadd__), enlarge and transform methods
     - callers use inplace add where possible now (yielding a considerable
       speedup)
    - "undefined" corners of bounding boxes are no longer supported which makes
      the bounding box operations much more efficient.
  - connnector module:
    - renamed _xxx -> xxx_pt
  - epsfile module:
    - removed showbbox argument of epsfile class
  - text module:
    - default handling of texmessages as in the new attribute scheme
    - multiple insert bug fixed
    - made left, right, width, height, depth information available (x length
      not taking into account box transformations)
    - ignore tex message "Please type a command or say `\\end'"
    - added textboxes that are sequentially filled (experimental)
  - examples:
    - mandel.py (contributed by Stephen Phillips)
  - unit module:
    - length comparision (David Beach)
    - x-scale for TeX
    - more unit tests
  - mathtree module:
    - switched to the new parser using pythons parser module
  - data module:
    - removed, it all lives in the graph.data module now, while before it
      was splitted into two separate modules
  - tex module:
    - not imported by default anymore
    - obsolete warning when importing this module

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] Comparing lengths

[David J. C. B. <be...@ve...>]

On Mon, 2004-03-08 at 02:10, Andre Wobst wrote:
> And about you patch ... is there a reason why having the id-comparion
> in the end? This looks totally unnatural to me ... did you step into
> troubles when not having this extra interpretation of the comparision
> operation???

Good question.  I did it just so that if the units (resulting from tom)
came out as equal, the lengths would still be considered different.=20
This was so that even if two lengths came out to be the same in
measurement, they would not be treated as identical.  As I think about
this more, it is probably a bad idea.  Maybe better to just use:

def __cmp__(self, other):
    return cmp(tom(self), tom(other))

Dave

--=20
David J. C. Beach
<be...@ve...>

Re: [PyX-devel] Comparing lengths

[Andre W. <wo...@us...>]

Hi David,

On 07.03.04, David J. C. Beach wrote:
> I've recently started using PyX to prepare a few presentation quality
> graphics and I really like the quality of output it produces.
> 
> I've been trying to add some "layout-management" type classes so that I
> can combine multiple images into larger layouts (such as grids/tables). 
> In so doing, I ran into the problem that instances of the unit.length()
> class do not numerically compare, but simply have the default
> "compare-by-id" behavior implemented by Python.  I don't like this at
> all.  :)
> 
> I patched my own installation of PyX to ammend this, and am offering the
> change here.  Can this go back into the distribution?

Of course, we can take this into the distribtion. But I would like to
hear a response from Jörg first (he wrote the unit-implementation).
While he's at a conference this week, we should wait until he's back.

> (in unit.length...)
> 
>     def __cmp__(self, other):
>         l1 = tom(self)
>         l2 = tom(other)
>         if l1 <> l2: return cmp(l1,l2)
>         return cmp(id(self), id(other))

I should tell you, that I do have similar problems in the graph
module. Here I have to compare lengths as well. While there is in
principle a possibility to internally work in PostScript points
already (there are _pt-like classes and methods almost everywhere like
path.line and path.line_pt), you can then only return PostScript
points or faked PyX lengths (as "true pt" and the like). The other
possibility is to manually convert the lengths into plain numbers
yourself before comparing. This is what I do in the graph module at
various places. I was not satisfied about adding a comparision like
you suggest it, because you can easily compare "apples and oranges" by
that. What about allowing for the comparision, when both parameters
are PyX lengths only? (This should be the case I'm doing in the graph
module all the time.) Would this be your use case as well? I would
feel much happier with that ...

And about you patch ... is there a reason why having the id-comparion
in the end? This looks totally unnatural to me ... did you step into
troubles when not having this extra interpretation of the comparision
operation???


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Comparing lengths

[David J. C. B. <be...@ve...>]

PyX Developers,

I've recently started using PyX to prepare a few presentation quality
graphics and I really like the quality of output it produces.

I've been trying to add some "layout-management" type classes so that I
can combine multiple images into larger layouts (such as grids/tables).=20
In so doing, I ran into the problem that instances of the unit.length()
class do not numerically compare, but simply have the default
"compare-by-id" behavior implemented by Python.  I don't like this at
all.  :)

I patched my own installation of PyX to ammend this, and am offering the
change here.  Can this go back into the distribution?

(in unit.length...)

    def __cmp__(self, other):
        l1 =3D tom(self)
        l2 =3D tom(other)
        if l1 <> l2: return cmp(l1,l2)
        return cmp(id(self), id(other))


Dave

--=20
David J. C. Beach
<be...@ve...>

[PyX-devel] [ pyx-Patches-861999 ] Graph Baseline Fixes

[SourceForge.net <no...@so...>]

Patches item #861999, was opened at 2003-12-17 23:18
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=861999&group_id=45430

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Graph Baseline Fixes

Initial Comment:
For PyX version 0.4.1

text.py:
        Add pdftex.map to the font list
        Increases tex timeout to 120

graph.py:
        Makes it so that axispainter can have a axis line 
painted at a value other than 0 (such as 1)
        Adds named parameter axiszeroline to 
graph.axispainter constructor.

        Allows bars to be graph from from a centerline other 
than 0 (such as 1)
        Adds named parameter baseline to graph.bar 
constructor



----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-02-24 08:27

Message:
Logged In: YES 
user_id=405853

The zeropath feature of the axispainter is removed in CVS head. This
whole feature is not worth the additional parameters it introduces. It is 
easy to stroke a path along a grid line yourself (there is an example in 
CVS, which shows it). Hence you can also stroke several gridlines like 
that ...

The feature you introduced for bars was indeed very nice. While I 
recently rewrote most of the graph styles I made the fromvalue a 
variable. Now you you can specify the position you want the bars to start
from like suggested by you.

While we now addressed all requested features by this patch (although
differently from the proposed way), I'm closing this patch now. Thanks
for the contribution.

----------------------------------------------------------------------

Comment By: Matthew Bridges (malkerei)
Date: 2003-12-23 00:31

Message:
Logged In: YES 
user_id=936473

First, thanks for the quick comments.  

In response to your comments, we didn't check the mailing 
archives before submitting the patch, so we didn't realize a better 
fix was already in CVS for the pdftex and timeout issues.

As for the baseline change, we kept fromzero around for 
backwards compatability, as we weren't sure how willing to break 
it you were.  Your way is how we wanted to do it.

Lastly, since there is already a parameter zerolineattrs specifically 
for the zero line, you've already made the 0 line special.  Why not 
make it a little more general and allow the line to be anywhere.

----------------------------------------------------------------------

Comment By: André Wobst (wobsta)
Date: 2003-12-19 12:18

Message:
Logged In: YES 
user_id=405853

There are several topics addressed in your patch. Let be briefly 
comment them:

The font map problem was addressed in CVS already. There is an 
option to add further map files within our PyX script. Additionally, 
you can specify map files in a ~/.pyxrc file (and a /etc/pyxrc 
IIRC). We're quite happy about that now and using psfonts.map as 
the default like dvips. Why should we change that (you may use 
the udpmap script to properly setup your psfonts.map)?

About the timeout: We had some discussion about that some time 
ago. The problem with a long timeout is, that the user might think, 
that the hole system hangs, while its just waiting for TeX. Its easy 
relatively easy to get into such a state (if you want to). Try:
    from pyx import *
    text.preamble(r"\def\PyXInput#1{}")
(Of course, nobody wants to do that, but there might be cases, 
where it is much more tricky.) However, there was a good solution 
suggested in a previous discussion, which is implemented in CVS 
now. See http://sourceforge.net/mailarchive/message.php?
msg_id=6332068.

About the zeroline I'm not sure, if this is really needed. You can 
always get a grid line from the graph and stroke that. So I'm not 
sure if we really want that. You can also use spcial ticks for that 
and plot gridlines (i.e. you can draw several lines by that). For 
bars the storry is quite different. It is really a good suggestion to 
add this feature. I like it. However, could you tell me, why we 
shouldn't do it the following way: Couldn't we get rid of the 
fromzero-flag and use the baseline parameter having a value or 
None? Then the name "baseline" might be worth a discussion as 
well ... but in principle I would like to add that feature this way ... 
what do you think? Would this be fine to you or do you have a 
good reason to add the "baseline" feature to both, the axes and 
the bar style?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=861999&group_id=45430

Re: [PyX-devel] Some questions about PyX.

[Andrea R. <ari...@pi...>]

Thanks for your answer Andre.

I've already written a new .info file for 0.5.1 version, I'll try to=20
get extension modules on this evening and I'll submit the new package=20
as soon as possible. Nevertheless I'm not a Fink's core developer and=20
I'm not allowed to update the Fink's tree itself, so we have to wait=20
for someone to accept the new package; sometime it take quite a long=20
time.

Regarding PyX project I was very pleased reading your answer. I=20
completely agree with you, there is place for PyX and people using=20
Python for scientific purpose will enjoy a complete and coherent=20
framework to produce both figures and plots. I'm working with=20
Python+Gnuplot during these days to produce some high-quality plots and=20=

I absolutely miss a tool like PyX will become.

My main interest, at the moment, is focused toward 2-dim plots=20
(contours and density plots), and I'll be happy to contribute to PyX in=20=

this topic. Could it be useful?

Unfortunately I'm not a skilled programmer (actually I'm only a "number=20=

cruncher" ;-P), and I'll need to study hard before being able to=20
contribute to PyX code. I hope to be ready soon.

Cheers,
	Andrea.

On 28 Jan 2004, at 01:45, Andre Wobst wrote:

> Hi Andrea,
>
> On 27.01.04, Andrea Riciputi wrote:
>> 1) I don't understand well what "C extension module" exactly are. Are
>> they C version of some cpu intensive task?
>
> In general it depends on the purpose of the extension module. They
> might be needed to speed up certain tasks. Another possibility is to
> make use of some existing C code or providing python bindings to an
> existing library.
>
> In PyX there are two extension modules. The first is a python binding
> to the libkpathsea library for fast directory structure searching
> issues. Once this library is initialized, the TeX/LaTeX/Font related
> searches becomes extremly fast compared to the fallback solution of
> running the kpathsea programm for each lookup (depending on the
> TeX/LaTeX path configuration in texmf.cnf the latter can be quite
> expensive). The second extension module t1strip reuses some code from
> pdftex for reducing font sizes by skipping unneeded glyphs. Since it
> reduces the output file size, it is quite nice to have.
>
>> 2) How can I decide whether I want to activate them or not?
>
> I strongly encourgage you to turn them on. In order to get the
> libkpathsea extension module compiled, you have to uncomment the
> build_ext lines. You should fill in
>     include_dirs=3D/sw/include
>     library_dirs=3D/sw/lib
> You should then be able to compile the extension modules. I'm a happy
> fink user nowadays (thanks to you and all the other maintainers for
> the great work!) and I hadn't had any problems in doing so. Please
> drop a note, if you get into troubles.
>
>> Last questions are much more related to my personal use of PyX. I've
>> looked at PyX source code and (even if I'm not a skilled programmer)=20=

>> it
>> seems very promising. AFAICU PyX is at the moment a tool very similar
>> to METAPOST, with the big difference that it has a high level=20
>> interface
>> (Python) and a much more modern design.
>
> ... and it is written in the same language as used by the users. I
> mean, for METAFONT/METAPOST you might need to deal with WEB in order
> to implement some new basic (builtin) functionality.
>
>> In the (I hope) near future you
>> have the intention to add many plotting capabilities to PyX (actually
>> some of them are already there) resulting in something like Biggles
>> (http://biggles.sourceforge.net/), but much more evoluted. So, at the
>> very last, PyX will be a very powerful tool with which we can do=20
>> figure
>> __and__ data plots, I mean METAPOST + (something like) Biggles
>> together.
>
> It was our intention from the very beginning to build a drawing *and*
> plotting library directly usable within an existing language with low
> overhead (instead of building an own language). It is quite important
> to have *one* tool for both tasks, drawing and plotting, since you can
> then always mix those tasks if you are in need of. We (e.g. J=F6rg,
> Gert, I myself) were users of gle (glx.sf.net) quite some time ago,
> which was able to do both tasks as well. Unfortunately gle was really
> buggy and bad designed (it doesn't make much sense to try to improve
> it, I think). It didn't use TeX for text processing (it tried to
> emulate TeX in some limited fashion ;-); once I wrote a extension for
> gle doing some hidden external real TeX processing, which was usable,
> but still totally ugly). At some point (after looking for alternatives
> including METAPOST) we decided to start with the PyX project. Although
> this was back in 2000 (our original discussions about a tool like PyX
> might be even a bit older), I think there is still a place for PyX.
> Other available software seems to not have filled this place we want
> PyX to be.
>
>> 3) Am I wrong? If I'm right, do you have any project plan? I mean, do
>> you have any idea about how long the entire path will take?
>
> In terms of some major design issues the 0.5 was a very important
> step. While the basic infra structure for the attribute handling is
> now in place and seems to work well, we still have to go thru all the
> code and make use of it. (For example the graph module is currently
> not using the new merging technique.) And I want to clean up the boxes
> (box module) and make them the basic clipping technique. These tasks
> are my major gool for 0.6. I will try hard to make a release of 0.6
> end of February already.
>
> I'm not sure how much the graph styles can be cleaned up in this
> release already. It is quite important, because after that cleanup
> further style implementations etc. should be possible from outside.
> Before this cleanup it is difficult to work on the graph except for
> the axes (which I consider ok compared to the rest). The timeaxis
> (probably using the great dateutil modules by Gustavo Niemeyer) are a
> long standing goal for me ... and could in principle be done right
> away ...
>
> Other things are pdf and svg support. Both should be possible and I
> would like to see them happen within the next year or so. I would like
> to see if the PyX design can be applied to other output formats. It
> should be (we kept it in mind for a long time already). For example
> one could start in making the fonts available for svg. Search for
> tubt1svg in google ... and start right away and implement something in
> python ... ;-)
>
>> 4) Can we (I mean we =3D users) contribute to the project? And how?
>
> One possiblility (the usual way) is to implement something you need
> yourself. You can than try to implemtent it "the PyX way". Decorators
> which wriggle a given path for example. I would really like to see
> those things. In case you have just no idea what to implement, ask and
> tell us some preferences. I'm sure we can give some hints where you
> could start ...
>
>
> Andr=E9
>
> --=20
> by  _ _      _    Dr. Andr=E9 Wobst
>    / \ \    / )   wo...@us..., http://www.wobsta.de/
>   / _ \ \/\/ /    PyX - High quality PostScript figures with Python &=20=

> TeX
>  (_/ \_)_/\_/           visit http://pyx.sourceforge.net/
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Pyx-devel mailing list
> Pyx...@li...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel
>
>
---
Andrea Riciputi

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)


---
Andrea Riciputi

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)

Re: [PyX-devel] Some questions about PyX.

[Andre W. <wo...@us...>]

Hi Andrea,

On 27.01.04, Andrea Riciputi wrote:
> 1) I don't understand well what "C extension module" exactly are. Are 
> they C version of some cpu intensive task?

In general it depends on the purpose of the extension module. They
might be needed to speed up certain tasks. Another possibility is to
make use of some existing C code or providing python bindings to an
existing library.

In PyX there are two extension modules. The first is a python binding
to the libkpathsea library for fast directory structure searching
issues. Once this library is initialized, the TeX/LaTeX/Font related
searches becomes extremly fast compared to the fallback solution of
running the kpathsea programm for each lookup (depending on the
TeX/LaTeX path configuration in texmf.cnf the latter can be quite
expensive). The second extension module t1strip reuses some code from
pdftex for reducing font sizes by skipping unneeded glyphs. Since it
reduces the output file size, it is quite nice to have.

> 2) How can I decide whether I want to activate them or not?

I strongly encourgage you to turn them on. In order to get the
libkpathsea extension module compiled, you have to uncomment the
build_ext lines. You should fill in
    include_dirs=/sw/include
    library_dirs=/sw/lib
You should then be able to compile the extension modules. I'm a happy
fink user nowadays (thanks to you and all the other maintainers for
the great work!) and I hadn't had any problems in doing so. Please
drop a note, if you get into troubles.

> Last questions are much more related to my personal use of PyX. I've 
> looked at PyX source code and (even if I'm not a skilled programmer) it 
> seems very promising. AFAICU PyX is at the moment a tool very similar 
> to METAPOST, with the big difference that it has a high level interface 
> (Python) and a much more modern design.

... and it is written in the same language as used by the users. I
mean, for METAFONT/METAPOST you might need to deal with WEB in order
to implement some new basic (builtin) functionality.

> In the (I hope) near future you 
> have the intention to add many plotting capabilities to PyX (actually 
> some of them are already there) resulting in something like Biggles 
> (http://biggles.sourceforge.net/), but much more evoluted. So, at the 
> very last, PyX will be a very powerful tool with which we can do figure 
> __and__ data plots, I mean METAPOST + (something like) Biggles 
> together.

It was our intention from the very beginning to build a drawing *and*
plotting library directly usable within an existing language with low
overhead (instead of building an own language). It is quite important
to have *one* tool for both tasks, drawing and plotting, since you can
then always mix those tasks if you are in need of. We (e.g. Jörg,
Gert, I myself) were users of gle (glx.sf.net) quite some time ago,
which was able to do both tasks as well. Unfortunately gle was really
buggy and bad designed (it doesn't make much sense to try to improve
it, I think). It didn't use TeX for text processing (it tried to
emulate TeX in some limited fashion ;-); once I wrote a extension for
gle doing some hidden external real TeX processing, which was usable,
but still totally ugly). At some point (after looking for alternatives
including METAPOST) we decided to start with the PyX project. Although
this was back in 2000 (our original discussions about a tool like PyX
might be even a bit older), I think there is still a place for PyX.
Other available software seems to not have filled this place we want
PyX to be.

> 3) Am I wrong? If I'm right, do you have any project plan? I mean, do 
> you have any idea about how long the entire path will take?

In terms of some major design issues the 0.5 was a very important
step. While the basic infra structure for the attribute handling is
now in place and seems to work well, we still have to go thru all the
code and make use of it. (For example the graph module is currently
not using the new merging technique.) And I want to clean up the boxes
(box module) and make them the basic clipping technique. These tasks
are my major gool for 0.6. I will try hard to make a release of 0.6
end of February already.

I'm not sure how much the graph styles can be cleaned up in this
release already. It is quite important, because after that cleanup
further style implementations etc. should be possible from outside.
Before this cleanup it is difficult to work on the graph except for
the axes (which I consider ok compared to the rest). The timeaxis
(probably using the great dateutil modules by Gustavo Niemeyer) are a
long standing goal for me ... and could in principle be done right
away ...

Other things are pdf and svg support. Both should be possible and I
would like to see them happen within the next year or so. I would like
to see if the PyX design can be applied to other output formats. It
should be (we kept it in mind for a long time already). For example
one could start in making the fonts available for svg. Search for
tubt1svg in google ... and start right away and implement something in
python ... ;-)

> 4) Can we (I mean we = users) contribute to the project? And how?

One possiblility (the usual way) is to implement something you need
yourself. You can than try to implemtent it "the PyX way". Decorators
which wriggle a given path for example. I would really like to see
those things. In case you have just no idea what to implement, ask and
tell us some preferences. I'm sure we can give some hints where you
could start ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Some questions about PyX.

[Andrea R. <ari...@pi...>]

Hi,
I'm Fink package maintainer for PyX and I'm looking into upgrading it 
to version 0.5.1. I'm very busy with my work, nevertheless I hope to 
get it upgraded very soon. In the meanwhile I have some questions; your 
answers can make the upgrade easier.

1) I don't understand well what "C extension module" exactly are. Are 
they C version of some cpu intensive task?

2) How can I decide whether I want to activate them or not?

Last questions are much more related to my personal use of PyX. I've 
looked at PyX source code and (even if I'm not a skilled programmer) it 
seems very promising. AFAICU PyX is at the moment a tool very similar 
to METAPOST, with the big difference that it has a high level interface 
(Python) and a much more modern design. In the (I hope) near future you 
have the intention to add many plotting capabilities to PyX (actually 
some of them are already there) resulting in something like Biggles 
(http://biggles.sourceforge.net/), but much more evoluted. So, at the 
very last, PyX will be a very powerful tool with which we can do figure 
__and__ data plots, I mean METAPOST + (something like) Biggles 
together. Now my questions:

3) Am I wrong? If I'm right, do you have any project plan? I mean, do 
you have any idea about how long the entire path will take?

4) Can we (I mean we = users) contribute to the project? And how?

Thanks in advance,
	Andrea.

---
Andrea Riciputi

"Science is like sex: sometimes something useful comes out,
   but that is not the reason we are doing it" -- (Richard Feynman)

[PyX-devel] Announcement: PyX 0.5.1 released

[Andre W. <wo...@us...>]

Hi,

I've just uploaded PyX 0.5.1. It fixes a distribution bug (the c files
for the optional extension modules were missing in PyX 0.5) and a
small PostScript DSC bug (unpaired Begin/End in fontreencoding).


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Announcement: PyX 0.5 released

[Andre W. <wo...@us...>]

Hi,

we are proud to announce the release of PyX 0.5. This release marks an
important development step towards a final design of the internal and
visible interfaces of PyX. The most prominent changes are:

- rewrite of the attribute system to improve both consistency and
  flexibility (this introduces new concepts, conventions and modules
  which renders this release not backward compatible; however,
  modifying existing code is not very difficult, since all the
  functionality is still avaiable)
- further improved TeX integration (integrated virtual font handling,
  configurable font mapping files, support for markers to access
  positions within the text, support for TeX's inter-process
  communication option,  split the dvifile reader from text module)
- some internal improvements in the graph module along with pathaxis
- streamlined install process (C extention modules for font stripping
  and path searching has become optional)
- new FAQ
- lots of small improvements and bug fixes

Find a more detailed list of changes below. Enjoy!

Jörg, Michael, André



---------


0.5 (2004/01/20):
  - setup.py and distribution:
    - allow customization of the extension modules built (via setup.cfg)
    - disable building pykpathsea module by default
    - more detailed description of install process in INSTALL
    - provide more information and pointers to other files in README
    - include example data files in distribution (suggested by Andrea Riciputi)
    - force dvips to write ps files instead of printing them (suggested by Otto Tronarp)
    - includ pyxfaq.pdf in distribution
  - text module:
    - improved is-readable test for lfs files and pyx.def file
    - explicitly quit (La)TeX in cleantmp (helps when quitting with <Ctrl>C)
    - showwaitfortex implemented following a suggestion by Fernando Perez
      (waitfortex is increased to 60 seconds now)
    - support of TeX extention --ipc for reading dvi results while TeX keeps running
    - configurable font mapping files (via pyxrc or parameter of the texrunner constructor)
    - markers to get access to positions within TeX expressions
    - fix: allow for e-tex in texmessage.start (reported by Andrea Riciputi)
    - fix: print warning at syntax errors in font mapping file and continue (cf. bug #795271)
    - remove limitation on number of fonts in dvi file
    - added native virtual font support
    - dvicopy support not needed anymore (it is still available, but obsolete and
      removed from the documentation)
    - do not include too many glyphs in the eps file
    - _xxx -> xxx_pt renaming
  - dvifile module (NEW):
    - separated from the text module
    - dvifile class returns standard pyx canvas instances on readpage
  - graph module:
    - removed manualpart and partitioners mix keyword
    - results of the splitting at "=" in graph.function were not stripped
    - skip title=None in key (cf. bug #821284), properly align a single key entry
    - another (the last?!) axis redesign: axispos -> class of its own
    - some axispos name have changed slightly (zeroline -> zeropath etc.)
    - tick/data-vmin/vmax removed
    - pathaxis
    - linkaxis
    - minor enhancements in exponentionaltexter
    - axes alongs paths including a set of examples
    - mixing a partitioner and manual ticks by two distinct keyword arguments now
    - _xxx -> xxx_pt renaming
    - part -> parter renaming
  - canvas module:
    - stroke, fill, draw, set and insert do no longer accept variable length argument lists but
      an attribute list as last argument
    - stroke and fill now support trafos (TODO: documentation)
    - uppercase version of a4, a3, ... paperformats
  - config module:
    - new module for loading PyX configuration information
  - pyx module:
    - automatically import main modules into pyx namespace as suggested by Fernando 
      Perez.
  - path module:
    - check for sorting of parameter list passed to path.split method
    - _xxx -> xxx_pt renaming
  - deco module (NEW): 
    - contains decoratedpath and decorators from canvas module
    - all predefined decorators are instances now (deco.stroked is thus ok) and 
      attributes have to be passed explicitely, e.g., deco.earrow.small(attrs=color.rgb.red) 
      and deco.stroked([color.rgb.blue])
  - style module (NEW):
    - contains all line- and fillstyles which formerly had been defined in the canvas module
    - dash now supports relative dash lengths (as suggested by Otto Tronarp)
  - mathtree module:
    - fixed incorrect handling of - (for instance -x**2 was not negative)
  - attrlist module:
    - contents have been moved to the (obsolete) tex module, which was the only user anyhow, and
      the module itself was removed
  - t1strip module:
    - new fallback solution in pure python
    - bugfix: pyxadapt.h needs to open files binary under Windows (reported by Gary Pajer)
  - box module:
    - _xxx -> xxx_pt renaming
  - trafo module:
    - _xxx -> xxx_pt renaming


-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] [ pyx-Patches-870431 ] data plotted can be ommited from key by passing title=None

[SourceForge.net <no...@so...>]

Patches item #870431, was opened at 2004-01-04 18:16
Message generated for change (Comment added) made by wobsta
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=870431&group_id=45430

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Bojan Nikolic (bnikolic)
Assigned to: Nobody/Anonymous (nobody)
Summary: data plotted can be ommited from key by passing title=None

Initial Comment:

I need to plot some data as symbols with error bars and
connected with lines. This was conveniently done by
plotting twice, once with a line style and once with a
symbol style (may be there is a different way?).
However, these then get included in the key twice.
Therefore this very small patch allows items to be
skipped from the key if the title is passed = None.



----------------------------------------------------------------------

>Comment By: André Wobst (wobsta)
Date: 2004-01-05 17:04

Message:
Logged In: YES 
user_id=405853

Thanks for submitting this issue.

You can use the symbol style with lineattrs=[] (instead of None; 
you may also add some stroke attributes there). But many people 
seem to fail to find this feature ... hence I already added a note in 
the CHANGES file to make it clearer in the implementation and the 
documentation.

But back to your main question: Yes indeed, it would be nice to be 
able to turn off some keys easily. This was already suggested in 
bug 821284 and is implemented in CVS already. Hence I'm closing 
this patch.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=870431&group_id=45430

[PyX-devel] [ pyx-Patches-870431 ] data plotted can be ommited from key by passing title=None

[SourceForge.net <no...@so...>]

Patches item #870431, was opened at 2004-01-04 17:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=870431&group_id=45430

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bojan Nikolic (bnikolic)
Assigned to: Nobody/Anonymous (nobody)
Summary: data plotted can be ommited from key by passing title=None

Initial Comment:

I need to plot some data as symbols with error bars and
connected with lines. This was conveniently done by
plotting twice, once with a line style and once with a
symbol style (may be there is a different way?).
However, these then get included in the key twice.
Therefore this very small patch allows items to be
skipped from the key if the title is passed = None.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=442888&aid=870431&group_id=45430

Re: [PyX-devel] valign.middle

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi Magnus,
>=20
> On 29.12.03, Magnus Lie Hetland wrote:
> > Ah, right. text.vshift.char was the only one I had problems with here
> > (that is, it wasn't there) :)
> >=20
> > So, that's basically what I meant -- that text.vshift.char is
> > deprecated. (Unless I misunderstand you?)
>=20
> Right. I removed it since it was a stupid design mistake (to my mind).
> Its removed in the doc as well already.

Right. I've been following the 0.4.1 docs for now :)

> Please note, that I consider the alpha development to do exactly
> those things -- which of course breaks code even without further
> notice (although usually its easy to correct those things).

Sure.

[snip]
> > Ah. I'll take a closer look. Thanks. (I've just browsed the docs
> > for what I *thought* I needed so far ;)
>=20
> So when building networks you may also start with boxes and take a
> look to the connector stuff Michael Schindler contributed a few
> months ago.

Yes, I've looked at it and it seems very nice.

> It should be quite usable (although it might be currently broken CVS
> -- I'm not sure about that). You could use it to connect different
> boxes (notes) ... I'm not sure if this would help you for the tasks
> you have in mind ...

It might indeed be useful.

> Andr=E9

--=20
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [PyX-devel] valign.middle

[Andre W. <wo...@us...>]

Hi Magnus,

On 29.12.03, Magnus Lie Hetland wrote:
> Ah, right. text.vshift.char was the only one I had problems with here
> (that is, it wasn't there) :)
> 
> So, that's basically what I meant -- that text.vshift.char is
> deprecated. (Unless I misunderstand you?)

Right. I removed it since it was a stupid design mistake (to my mind).
Its removed in the doc as well already. Please note, that I consider
the alpha development to do exactly those things -- which of course
breaks code even without further notice (although usually its easy to
correct those things). We might get into beta next year, where those
breakage should become rare and should be documented. We'll see.

> [snip]
> > Or you take a look at the box align methods ... linealign and
> > circlealign. It can perform more complicated alignment tasks very
> > well.
> 
> Ah. I'll take a closer look. Thanks. (I've just browsed the docs for
> what I *thought* I needed so far ;)

So when building networks you may also start with boxes and take a
look to the connector stuff Michael Schindler contributed a few months
ago. It should be quite usable (although it might be currently broken
CVS -- I'm not sure about that). You could use it to connect different
boxes (notes) ... I'm not sure if this would help you for the tasks
you have in mind ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] valign.middle

[Andre W. <wo...@dp...>]

Hi Jörg,

On 29.12.03, Joerg Lehmann wrote:
> >     def merge(self, attrs):
> >         return attr.sortbeforeattr.merge(self, attr.exclusiveattr.merge(self, attrs)[:-1])
> 
> Hmm, this assumes implicitly that attr.exclusiveattr.merge returns self as
> last element in the list -- which is currently the case.

Well, it should be the last element since it doesn't modify the order
of the attributes but removes unneeded entries (which come before the
last element). But you're right, its quite implicit ...

I mean, when I realized (again), that a new merge method is needed
when we use both, exculsiveattr and sorfbeforeattr, I was already
sure we want to have it once and for all.

> > We may add a combined exclusive and sort attr because we do have this
> > merge code several times in the attributes already ... what do you
> > think?
> 
> Taking into account the problem mentioned above, I think this is a
> good idea. So what about a sortbeforeexclusiveattr class? If there
> are no objections, I'll go ahead and implement this.

Ok, please do so. It should be straigt forward. The name you suggested
is kind of lengthly, but I think, its ok for that task, since its
really part of the internal attribute system ... (and multiple
inheritance of both parts was even longer to type not even taking into
account the merge method).


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] valign.middle

[Joerg L. <jo...@us...>]

Hi André,

On 28.12.03, Andre Wobst wrote:
<snip>
> I've now restored the valign.middle (the old implementation was ok)
> using the new attribute system. Jörg: please take a look at the merge
> method when combining exclusiveattr and sortbeforeattr (I've corrected
> it style.linewidth as well). The attribute should not be added twice.
> Thus the code looks like:
> 
>     def merge(self, attrs):
>         return attr.sortbeforeattr.merge(self, attr.exclusiveattr.merge(self, attrs)[:-1])

Hmm, this assumes implicitly that attr.exclusiveattr.merge returns self as
last element in the list -- which is currently the case.

> We may add a combined exclusive and sort attr because we do have this
> merge code several times in the attributes already ... what do you
> think?

Taking into account the problem mentioned above, I think this is a
good idea. So what about a sortbeforeexclusiveattr class? If there
are no objections, I'll go ahead and implement this.

        Jörg

Re: [PyX-devel] valign.middle

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi Magnus,
>=20
> On 29.12.03, Magnus Lie Hetland wrote:
> > Well, I tried to use text.vshift.char(0.5), but that didn't work
> > (deprecated?). Is that the same as text.vshift(0.5)?
>=20
> No, its not deprecated. It's an important feature! It might have been
> broken in some cases in the CVS before yesterday. (It was broken due
> to some sorting problem of the attributes -- it should work now
> again.) And to your question: text.vshift(0.5) should work. It is the
> same like text.vshift.middlezero; text.vshift.char is removed in CVS
> since it was not needed anymore after some cleanups.

Ah, right. text.vshift.char was the only one I had problems with here
(that is, it wasn't there) :)

So, that's basically what I meant -- that text.vshift.char is
deprecated. (Unless I misunderstand you?)

[snip]
> Or you take a look at the box align methods ... linealign and
> circlealign. It can perform more complicated alignment tasks very
> well.

Ah. I'll take a closer look. Thanks. (I've just browsed the docs for
what I *thought* I needed so far ;)

> > Anyway, thanks for your help. I'll experiment a bit with shifting and
> > aligning and see what I end up with. (Maybe I'll just use dotted node=
s
> > with external labels.)
>=20
> Have you seen the text style of the graph module? I do know this code
> is not documented. I'm working on a cleanup and documentation of the
> hole graph module and it goes well, although it takes a long time. For
> the moment this code to take a look at is all I can offer ... but it
> sounds like you want to do something simular.

Actually, by graph I mean network -- not the kind of graphs in the PyX
graph modules. The graph module looks very good for that sort of
thing.

> The test_graph.py in the functional test directory uses this code
> and should be working in the current state. But I'm currently doing
> xy-graphs only, although many things are designed to work for
> different graph geometries as well ...  we'll see in the future.

Sounds good -- but, as I said, what I'm working on at the moment is
graphs in the network sense. Nodes and edges with various forms of
highlighting to indicate various stages of an algorithms etc.

> Andr=E9

--=20
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [PyX-devel] valign.middle

[Andre W. <wo...@us...>]

Hi Magnus,

On 29.12.03, Magnus Lie Hetland wrote:
> Well, I tried to use text.vshift.char(0.5), but that didn't work
> (deprecated?). Is that the same as text.vshift(0.5)?

No, its not deprecated. It's an important feature! It might have been
broken in some cases in the CVS before yesterday. (It was broken due
to some sorting problem of the attributes -- it should work now
again.) And to your question: text.vshift(0.5) should work. It is the
same like text.vshift.middlezero; text.vshift.char is removed in CVS
since it was not needed anymore after some cleanups.

> If I place several nodes alongside each other, it may be good to have
> the labels aligned by their baselinge, so that (e.g.) b and g are
> properly aligned. However, if the nodes are scattered all over the
> place, simply aligning based on the total height of the character will
> "fill out" the node more, and seem less vertically skewed. (I could,
> of course, use only capital letters... Or numbers... Then there would
> be no problem :)

Or you take a look at the box align methods ... linealign and
circlealign. It can perform more complicated alignment tasks very
well.

> Anyway, thanks for your help. I'll experiment a bit with shifting and
> aligning and see what I end up with. (Maybe I'll just use dotted nodes
> with external labels.)

Have you seen the text style of the graph module? I do know this code
is not documented. I'm working on a cleanup and documentation of the
hole graph module and it goes well, although it takes a long time. For
the moment this code to take a look at is all I can offer ... but it
sounds like you want to do something simular. The test_graph.py in the
functional test directory uses this code and should be working in the
current state. But I'm currently doing xy-graphs only, although many
things are designed to work for different graph geometries as well ...
we'll see in the future.


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

[PyX-devel] Pixmaps?

[Magnus L. H. <ma...@he...>]

Just wondered: Have you thought about pixmap functionality in PyX? I
suppose one could simply use the Python Imaging Library to generate
EPS and then include that in PyX -- perhaps that is the easiest
solution?

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [PyX-devel] valign.middle

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
[snip]
> This might be a sourceforge problem. They had quite some performance
> problems with the CVS.

Indeed -- it's there now :)

[snip]
> Another note about your original problem with the valign: Did you
> consider a baseline alignment and an appropriate vertical shift?

Well, I tried to use text.vshift.char(0.5), but that didn't work
(deprecated?). Is that the same as text.vshift(0.5)?

> You gain a vertical alignment independend of the box extent. See the
> valign example ...

This might be a possibility. What I need this for at the moment is
placing labels in circular graph nodes. I'm thinking about writing an
automated graph algorithm visualization program (for producing slides
for an algorithm class I'm teaching), and PyX seems like a good thing
to use. (I'll probably write a separate module for graph drawing,
which might be useful to other PyX users as well.)

If I place several nodes alongside each other, it may be good to have
the labels aligned by their baselinge, so that (e.g.) b and g are
properly aligned. However, if the nodes are scattered all over the
place, simply aligning based on the total height of the character will
"fill out" the node more, and seem less vertically skewed. (I could,
of course, use only capital letters... Or numbers... Then there would
be no problem :)

Anyway, thanks for your help. I'll experiment a bit with shifting and
aligning and see what I end up with. (Maybe I'll just use dotted nodes
with external labels.)

> Andr=E9

--=20
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [PyX-devel] valign.middle

[Andre W. <wo...@us...>]

Hi Magnus,

On 28.12.03, Magnus Lie Hetland wrote:
> > I've now restored the valign.middle (the old implementation was ok)
> > using the new attribute system.
> 
> Ah -- good. (It doesn't seem to be checked into CVS yet, though...?)

This might be a sourceforge problem. They had quite some performance
problems with the CVS. Originally they moved the anonymous login (and
the CVS web access) to a read only copy, which is updated with up to
24 hours delays. Now they have new maschines for the CVS, but the
delay might still be present ... I'm not reading the sourceforge
announcements carefull to know the current state accurately.

(The CVS statistics is broken for months now as well ... we did a lot
of development and there is a "0" all the time ;-()

Another note about your original problem with the valign: Did you
consider a baseline alignment and an appropriate vertical shift? You
gain a vertical alignment independend of the box extent. See the
valign example ...


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] valign.middle

[Magnus L. H. <ma...@he...>]

Andre Wobst <wo...@us...>:
>
> Hi Magnus,

Hi!

> Yes, valign.middle was removed by accident as noted in CHANGES and the
> source. I likely happened when I moved the code to the new attribute
> system and I couldn't do much more then writing a note because I was
> traveling when I noticed it
[snip]

I see :)

> I've now restored the valign.middle (the old implementation was ok)
> using the new attribute system.

Ah -- good. (It doesn't seem to be checked into CVS yet, though...?)

-- 
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [PyX-devel] valign.middle

[Andre W. <wo...@us...>]

Hi Magnus,

On 27.12.03, Magnus Lie Hetland wrote:
> > What concerns the valign attribute, I think that André plans to
> > change something, but I'm not sure about that...
> 
> Right -- I'll just wait and see, then :)

Yes, valign.middle was removed by accident as noted in CHANGES and the
source. I likely happened when I moved the code to the new attribute
system and I couldn't do much more then writing a note because I was
traveling when I noticed it (I don't have access to CVS when I'm on
the train, where I did most of the develoment during the last weeks --
well, I didn't did much develoment during the last weeks at all, but
I'll hopefully get more time for the development in near future).

I've now restored the valign.middle (the old implementation was ok)
using the new attribute system. Jörg: please take a look at the merge
method when combining exclusiveattr and sortbeforeattr (I've corrected
it style.linewidth as well). The attribute should not be added twice.
Thus the code looks like:

    def merge(self, attrs):
        return attr.sortbeforeattr.merge(self, attr.exclusiveattr.merge(self, attrs)[:-1])

We may add a combined exclusive and sort attr because we do have this
merge code several times in the attributes already ... what do you
think?


André

-- 
by  _ _      _    Dr. André Wobst
   / \ \    / )   wo...@us..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript figures with Python & TeX
 (_/ \_)_/\_/           visit http://pyx.sourceforge.net/

Re: [PyX-devel] valign.middle

[Magnus L. H. <ma...@he...>]

Joerg Lehmann <jo...@us...>:
>
[snip]
> Due to a rewrite of the attribute system (see a message to pyx-user sen=
t
> by Andr=E9 a few days ago:
> http://sourceforge.net/mailarchive/message.php?msg_id=3D6684291),

OK. I noticed that the code had changed.

> at the moment, the CVS code is not really in a fully usable state.

OK. I just couldn't get 0.4.1 to work properly, but the CVS version
seemed quite a bit better wrt. compiling the extensions and the like.

> What concerns the valign attribute, I think that Andr=E9 plans to
> change something, but I'm not sure about that...

Right -- I'll just wait and see, then :)

>         J=F6rg

--=20
Magnus Lie Hetland           "The mind is not a vessel to be filled,
http://hetland.org            but a fire to be lighted."  [Plutarch]

Re: [PyX-devel] valign.middle

[Joerg L. <jo...@us...>]

Hi Magnus,

On 27.12.03, Magnus Lie Hetland wrote:
> I need valign.middle and noticed that it didn't work in the CVS
> version. Upon looking in the source, I saw the comment "class
> _valignmiddle is missing!". Why has it been removed? Was the old one
> unsatisfactory/non-functional?

Due to a rewrite of the attribute system (see a message to pyx-user sent
by André a few days ago:
http://sourceforge.net/mailarchive/message.php?msg_id=6684291), at the
moment, the CVS code is not really in a fully usable state. What
concerns the valign attribute, I think that André plans to change
something, but I'm not sure about that...

        Jörg