|
From: Andre W. <wo...@us...> - 2004-01-28 00:45:30
|
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/
|