Hi Peter,
On 30.11.04, Peter Falloon wrote:
> Thanks for that, everything works again now! Meanwhile, I hate to
> bother you again, but I've decided to try and create a set of feynman
> diagrams (of the kind used to calculate weak localization etc, i.e.
> cooperons and diffusons and so on). I think ultimately getting a good
> set of diagrams would be a very useful application of pyx. The first
> step is to create an oval-shaped curve. I've been looking but I don't
> see a simple way to do this. Ideally, there would be an optional extra
> argument to circle which would allow to elongate along x or y axis. The
> other option, which seems much less elegant, is to perform a linear
> transformation on the circle, but this doesn't seem to work. Is there a
> simple way to generate an oval?
No. Its actually what PostScript offers (IIRC). If you want to draw an
elipse, you have to transform a circle. However, you can also use
bezier curves to nicely build those kind of shapes.
> Finally, the diagrams have wiggly lines (roughly sinusoidal) attached
> at either end to represent the velocity operator. It would be great if
> there were a "deformer" which give a wiggly line instead of a cycloid.
> Are there plans to extend the "deformer" functions in the future?
(I basically do know how feynman diagrams look like and I even do
understand in principle what they stand for -- thanks to Gert!)
There are several things to be addressed here. You want to connect
nodes. This is something you could make use of connectors. Those nodes
are called boxes in the (current) language of PyX. These are graphical
objects with a border, where we currently have a limitation to
polygons but this is subject of change for the future (i.e. circles
and the like should become possible in the future). As soon as you
have connection lines, you could take advantage of deformers to create
those wiggled lines. (It actually funny, that the cycloid, as we have
it now, was originally a replacement for a wiggler (which I
mistakeably called wriggler in my implementation) I wrote almost a
year ago. It was more or less a design test and an example of what
kind of path operations I had in mind that time. I was concentrating
on a spring-like design as the real cycloid does it now as well.)
The wiggler deformer, as you would like to have it, should be a
different deformer than the cycloid. I think its not a good idea to
build one huge and complicated deformer which is a huge collection of
all kind of strange deform operations. Instead, we should have several
small and handy deformers (also in terms of there parameter list),
which OTOH could share some code by inheritance between each other.
There's another thing worth some thoughts in the design phase of such
a "framework" for feynman diagrams. Stroking arrows at the paths (at
the end or in the middle of a path) should be straight forward. Such
an arrow would be a decorator, not a deformer, by the way. But what I
would take care of from the very beginning are those double lines. I'm
not totally sure how those should be created starting from a
connecting path in the beginning. Should we start to have two paths
for that case. I don't think so ... but I do not have strong arguments
at hand.
Since Michael has spend quite some time in writing the connectors and
the cycloid deformer, we might get him (and possibly others) included
in the discussion. Thus I'm just cross-posting this answer to
pyx-devel. Take it into account when answering, that Peter might not
(yet ;-)) be a subscriber of pyx-devel ...
André
--
by _ _ _ Dr. André Wobst
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX
(_/ \_)_/\_/ visit http://pyx.sourceforge.net/

Hi,
On 06.12.04, Andre Wobst wrote:
> Could we summarize a bit, what we should take care off before
> releasing? The tipa issue. Sure. Other things, which somebody has in
> the queue?
I just realized that about a week ago somebody asked me for an example
on how to use error bars. I came up with a slightly modified version
of minimal.py. I just enclose it here. I'm not so sure whether its
worth to be included. I just don't have a clear feeling on the value
what this example has to a beginner. In principle I think we should
avoid to have several examples showing the same features ...
Comments?
André
--
by _ _ _ Dr. André Wobst
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX
(_/ \_)_/\_/ visit http://pyx.sourceforge.net/

Hi,
On 03.12.04, Andrea Riciputi wrote:
> >In principle, I would also like to release a new version, but I know
> >that André has a lot of work to do at the moment. In principle, I could
> >also prepare the release alone. But this may not be the best idea
> >because my PyX release experience lately became a little bit rusty.
While I was completely blocked during the last weeks due to some
conference organization and performing the copy deadline for the
abstract books (the conference consists of 6200+ contributions and the
conference booklet does actually consist of 5 parts), I see the end of
the work at the horizon and expect to get everything out to the print
office by the end of this week.
Thus I'm confident that I could spend some time in preparing 0.7.1
over the weekend or early next week. And I think it would be worth the
effort, since we accumulated some patches and we do have this missing
INDEX file issue in the current release (which was new in this
release). Although we managed to don't have some real show-stoppers in
the current release, a polishing release might be a good idea, since
it will take some time to work out some of the future goals to get a
real new release.
Could we summarize a bit, what we should take care off before
releasing? The tipa issue. Sure. Other things, which somebody has in
the queue? (I do have some enhancements of the pdfwriter in a private
development tree, which basically enhances the pdfwriter to what we
had in our first experiments in pdf writing (creating text etc.). I
could commit that, but it doesn't really matter. I didn't had time to
continue the development lately. In order to keep the release close to
what we had, I think its better to keep it off.)
André
--
by _ _ _ Dr. André Wobst
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX
(_/ \_)_/\_/ visit http://pyx.sourceforge.net/

Hi,
On 06.12.04, Gert Ingold wrote:
> > If there is not any other "more" standard package to produce phonetic
> > transliteration, the png solution it should be ok.
>
> tipa is usually considered to be *the* package for phonetic typesetting.
> I will try to come up with a working png solution. (Andre, Jörg: do you
> agree?)
I totally agree. And I do not really like the idea to give up tipa due
to the dependency it creates for *building* a package. (I think the
final package would not need to have this dependency.) For the
official build as we distribute it on the PyX webpage (note that we
decided to skip distributing the compiled manual and faq within the
distribution to greatly reduce its memory footprint after some
discussion on this list or the users list -- I don't remember exactly)
I would like to keep the tipa solution.
However, I see the point of wanting a tipa-free ability to generate a
almost optimal form of the faq. There are two possibilities: allow for
a build by just skipping the phonetic transliterations or generate
png's (pdf's?) for the usecases we need and include it in the
distribution. The pdf-solution, when it's possible, might be a way to
completely remove the tipa dependency as soon as you have the pdf
snipplets, which we could include in the distribution. This might be a
way out of splitting the faq-generation into an full and a poor man's
solution. Somebody how wants to try whether this option is not just a
rash thought?
André
--
by _ _ _ Dr. André Wobst
/ \ \ / ) wobsta@..., http://www.wobsta.de/
/ _ \ \/\/ / PyX - High quality PostScript figures with Python & TeX
(_/ \_)_/\_/ visit http://pyx.sourceforge.net/

Hi,
> If there is not any other "more" standard package to produce phonetic
> transliteration, the png solution it should be ok.
tipa is usually considered to be *the* package for phonetic typesetting.
I will try to come up with a working png solution. (Andre, J=F6rg: do you
agree?)
Best regards,
Gert
--=20
Gert-Ludwig Ingold email: Gert.Ingold@...
Institut f=FCr Physik Phone: +49-821-598-3234
Universit=E4t Augsburg Fax : +49-821-598-3222
D-86135 Augsburg WWW : http://www.physik.uni-augsburg.de/theo1/ingold
Germany PGP : 86FF5A93, key available from homepage