pyx-devel — PyX development

Re: [PyX-devel] Curves with infinite curvature

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

Hi Michael,

[ sorry, I forgot to CC the list before, here it goes again ]

n 09.09.05, Michael Schindler wrote:
> On 09.09.05, Joerg Lehmann wrote:
> > On 09.09.05, Michael Schindler wrote:
> > > On 09.09.05, Joerg Lehmann wrote:
> > > > Hi Michael!
> > > > 
> > > > On 09.09.05, Michael Schindler wrote:
> > > > > I have hit a problem concerning the geometry things of the normpaths.
> > > > > Consider a Bezier curve that contains a point with infinite curvature.
> > > > > This is very easy to produce by setting e.g. the last two points to
> > > > > the same coordinates
> > > > > 
> > > > >   n = normcurve_pt(0,0, 1,1, 1,0, 1,0)
> > > > 
> > > > I think, we should return the correct rotation instead of None.
> > > 
> > > That is my problem. If you have infinite curvature, there is no
> > > geometrically defined rotation. Because the curvature is the change of
> > > the normal vector along the curve length, projected onto the tangent
> > > vector (or equally the other way round), you see that both vectors
> > > change infinitely fast. Thus, they do not exist in this point.
> > 
> > Maybe I'm missing the point, but for me the rotation doesn't have
> > anything to do with the curvature, but is solely defined in terms of
> > the tangent.
> 
> Correct. The tangent is not defined in such point.

Ok, this sounds reasonable.

> This is what I have learned some years ago in a lecture on
> differential geometry: Consider a parameterization of a curve. The
> parameterization can be C-infty. But: if the length "velocity" (dx/dt,
> dy/dt) is zero somewhere, you can easily create a cusp in that curve.
> So, the curve is not smooth anymore, and in that cusp the tangent
> vector is not continuous: From both sides the tangents approach
> different values.

Ah, ok, the limits from above and below do not agree. But in the output,
there is no cusp because we do not see the behaviour for param > 1.
Hmm...

> > So I would assume that we take the limiting case of the rotation defined
> > by the tangent as param->1. This you can easily calculate via l'Hopital
> > and it gives you (-1, 0) in the present case.
> 
> In the present case we have only one side to do this. It would be very
> nice if already this worked. Nevertheless, the problem remains if the
> parameterization velocity vanishes somewhere in the middle.

Can this happen in the case of Bézier curves?

> > Having said all that, I just want to remark that Ghostscript also
> > isn't quite a fan of a Bézier curve with two identical control points.
> > Just try to stroke the above normpath and view the resulting EPS
> > file...
> 
> Well, my ghostscript does not complain. But the tangent does not seem
> to be (-1, 0) at the end.

Ah, sorry, of course it works, there was another problem. And yes, the
tangent does not looks like being (-1, 0) at then end, although this is
the limit from below. I'm really getting confused now.

> > So, maybe we're discussing a point which is quite academical anyway.
> 
> I tapped into this while writing the parallel deformer where infinte
> curvatures are a big issue.

I suspected something like this...

    Jörg

Re: [PyX-devel] Curves with infinite curvature

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

Hi Michael!

On 09.09.05, Michael Schindler wrote:
> I have hit a problem concerning the geometry things of the normpaths.
> Consider a Bezier curve that contains a point with infinite curvature.
> This is very easy to produce by setting e.g. the last two points to
> the same coordinates
> 
>   n = normcurve_pt(0,0, 1,1, 1,0, 1,0)
> 
> The curveradius_pt returns "None" for parameter value 1. But the
> trafo/rotation does something quite unexpected. The tangent vector
> 
>   n.rotation([0.999999])[0].apply_pt(1, 0)
> 
> seems to converge against (-1, 0) while adding more "9"s to the
> parameter. However, the tangent at the parameter value 1 is (1, 0).
> 
> My question now is, how well do we want to really reproduce the true
> underlying geometry? We should return "None" for the rotation at such
> points also.

I think, we should return the correct rotation instead of None.
Geometrically, everything is well-defined, it's only that we commit some
numerical error because the length of (dx/dt, dy/dt) goes to zero. But
we should be able to treat this case better.

        Jörg

[PyX-devel] Curves with infinite curvature

[Michael S. <m-s...@us...>]

Hello,

I have hit a problem concerning the geometry things of the normpaths.
Consider a Bezier curve that contains a point with infinite curvature.
This is very easy to produce by setting e.g. the last two points to
the same coordinates

  n = normcurve_pt(0,0, 1,1, 1,0, 1,0)

The curveradius_pt returns "None" for parameter value 1. But the
trafo/rotation does something quite unexpected. The tangent vector

  n.rotation([0.999999])[0].apply_pt(1, 0)

seems to converge against (-1, 0) while adding more "9"s to the
parameter. However, the tangent at the parameter value 1 is (1, 0).

My question now is, how well do we want to really reproduce the true
underlying geometry? We should return "None" for the rotation at such
points also.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

Re: [PyX-devel] Problems building manual.pdf

[Michael S. <m-s...@us...>]

On 08.09.05, Andrea Riciputi wrote:
> On Sep 7, 2005, at 7:33 PM, Andre Wobst wrote:
> Probably we don't understand each other. What I said (or at least  
> tried to) is that in the Makefile that comes with 0.8.1 tarball the  
> pdf version of the manual *does not* depend on the eps target. The  
> original Makefile reads:
> 
> >manual.pdf: $(src)
> 
> while it should read:
> 
> >manual.pdf: $(src) eps
> 
> Correcting the Makefile in this way solves the problem.

Good. I have checked it in similar to this. Unfortunately your patch
in one of the previous mails got mixed up, but your statement shows me
that I have guessed right.

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

Re: [PyX-devel] Problems building manual.pdf

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

On Sep 7, 2005, at 7:33 PM, Andre Wobst wrote:

> Well, I don't understand that. It is correct, that the pdf version of
> the manual depends on the eps target. Note, that the pdf target just
> runs all python files for the figures and they create a eps and a pdf
> version of that very figure at the same time.

Probably we don't understand each other. What I said (or at least  
tried to) is that in the Makefile that comes with 0.8.1 tarball the  
pdf version of the manual *does not* depend on the eps target. The  
original Makefile reads:

> manual.pdf: $(src)

while it should read:

> manual.pdf: $(src) eps

Correcting the Makefile in this way solves the problem.

Regarding the other issue, the workaround proposed by Micheal works  
and I've adopted it for the Fink's package that I'm setting up.

Hope to have been clear this time.

Cheers,
  Andrea.

Re: [PyX-devel] Problems building manual.pdf

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

Hi,

On 07.09.05, Andre Wobst wrote:
> ... but there seems to be no rule to create the actual pdf files. It
> should be identical to the "%.eps: %.py" rule.

Crap. It seems to be, that there was such a rule before already and
that's why I didn't found it in the diff. Everything is fine in that
respect ...


André

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

Re: [PyX-devel] Problems building manual.pdf

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

Hi,

On 06.09.05, Michael Schindler wrote:
> > >! Undefined control sequence.
> > >\filenq #1->{\py@smallsize \textsf {\let \e
> > >                                            =\textbackslash #1}}
> > >l.44 ... for the data from file \file{graph.dat}.}
> > >
> > >?
> > >! Emergency stop.
> > >\filenq #1->{\py@smallsize \textsf {\let \e
> > >                                            =\textbackslash #1}}
> > >l.44 ... for the data from file \file{graph.dat}.}
> 
> I do not understand this either, but I had the same problem.
> Strange enough, if you define \e in any way, either using \def or
> 
>   \let\e=\textbackslash
> 
> at the beginning of graph.tex, there is no error anymore, and
> everything works.

It seems to depend on the pdftex version used. At least for my old
pdftex I'm using (it's version 1.10b from an old teTeX 2.02 or
something). However, Michaels work around seems to solve the issue, so
let's keep it for the moment.

On 06.09.05, Andrea Riciputi wrote:
> manual.pdf file didn't build correctly. It turned out that the  
> problem was twofold. First the manual/Makefile has got an error and  
> here it is the patch:
> 
> >*** /Users/andrea/Installs/Python/PyX-0.8.1/manual/Makefile.orig    
> >Tue Sep  6 16:43:38 2005
> >--- /Users/andrea/Installs/Python/PyX-0.8.1/manual/Makefile     Tue  
> >Sep  6 16:46:43 2005
> >***************
> >*** 22,28 ****   
> >pdf:manual.pdf                                                         
> >                                        html:manual/manual.html
> >! manual.pdf: $(src)
> >        #for index-with-own-hyperrefs debugging, anybody interested?
> >        #./mkhowto --a4 --pdf --keep manual.tex
> >        ./mkhowto --a4 --pdf manual.tex
> >--- 22,28 ----
> >  pdf:manual.pdf
> >  html:manual/manual.html
> >
> >! manual.pdf: $(src)  
> >eps                                                                    
> >                           #for index-with-own-hyperrefs debugging,  
> >anybody  
> >interested?                                                  #./ 
> >mkhowto --a4 --pdf --keep  
> >manual.tex                                                             
> >           ./mkhowto --a4 --pdf manual.tex

Well, I don't understand that. It is correct, that the pdf version of
the manual depends on the eps target. Note, that the pdf target just
runs all python files for the figures and they create a eps and a pdf
version of that very figure at the same time.

On 07.09.05, Michael Schindler wrote:
> Update of /cvsroot/pyx/pyx/manual
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv17910
> 
> Modified Files:
> 	Makefile 
> Log Message:
> make manual.pdf depend on pdf (comment by Andrea Riciputi) figures and rename the figure rules
> 
> Index: Makefile
> ===================================================================
> RCS file: /cvsroot/pyx/pyx/manual/Makefile,v
> retrieving revision 1.22
> retrieving revision 1.23
> diff -C2 -d -r1.22 -r1.23
> *** Makefile	13 Aug 2005 12:24:11 -0000	1.22
> --- Makefile	7 Sep 2005 16:32:32 -0000	1.23
> ***************
> *** 6,10 ****
>   # for details).
>   
> ! default:dvi
>   
>   clean:
> --- 6,10 ----
>   # for details).
>   
> ! default: dvi
>   
>   clean:
> ***************
> *** 19,35 ****
>   src=$(wildcard *.tex) pyxversion.tex pyxdate.tex
>   
> ! dvi:manual.dvi
> ! pdf:manual.pdf
> ! html:manual/manual.html
>   
> ! manual.pdf: $(src)
>   	#for index-with-own-hyperrefs debugging, anybody interested?
>   	#./mkhowto --a4 --pdf --keep manual.tex
>   	./mkhowto --a4 --pdf manual.tex
>   
> ! manual.dvi: $(src) eps
>   	./mkhowto --a4 --dvi manual.tex
>   
> ! manual/manual.html: $(src) eps
>   	./mkhowto --image-type png --favicon "/pyx.ico" \
>   	          --up-link "/" --up-title "PyX homepage" \
> --- 19,35 ----
>   src=$(wildcard *.tex) pyxversion.tex pyxdate.tex
>   
> ! dvi: manual.dvi
> ! pdf: manual.pdf
> ! html: manual/manual.html
>   
> ! manual.pdf: $(src) pdf_figs
>   	#for index-with-own-hyperrefs debugging, anybody interested?
>   	#./mkhowto --a4 --pdf --keep manual.tex
>   	./mkhowto --a4 --pdf manual.tex
>   
> ! manual.dvi: $(src) eps_figs
>   	./mkhowto --a4 --dvi manual.tex
>   
> ! manual/manual.html: $(src) eps_figs
>   	./mkhowto --image-type png --favicon "/pyx.ico" \
>   	          --up-link "/" --up-title "PyX homepage" \
> ***************
> *** 42,48 ****
>   	python -c "import sys;sys.path[:0]=[\"..\"];import pyx.version;print pyx.version.date+'%'" > pyxdate.tex
>   
> ! eps: $(patsubst %.py, %.eps, $(wildcard *.py))
>   
> ! pdf: $(patsubst %.py, %.pdf, $(wildcard *.py))
>   
>   %.eps: %.py
> --- 42,48 ----
>   	python -c "import sys;sys.path[:0]=[\"..\"];import pyx.version;print pyx.version.date+'%'" > pyxdate.tex
>   
> ! eps_figs: $(patsubst %.py, %.eps, $(wildcard *.py))
>   
> ! pdf_figs: $(patsubst %.py, %.pdf, $(wildcard *.py))
>   
>   %.eps: %.py
> 

... but there seems to be no rule to create the actual pdf files. It
should be identical to the "%.eps: %.py" rule. While overall the eps
and pdf generation at the same time seems a bit strange to be handled
in the Makefile, it seems to have worked very well on an unbroken
pdftex all the time ...


André

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

Re: [PyX-devel] Problems building manual.pdf

[Michael S. <m-s...@us...>]

Hello Andrea,

On 06.09.05, Andrea Riciputi wrote:
> The second problem is more subtle and I haven't understood it  
> completely. After patching the Makefile as show above, the  
> compilation of the manual fails while processing graph.tex with the  
> following error message:
> 
> >! Undefined control sequence.
> >\filenq #1->{\py@smallsize \textsf {\let \e
> >                                            =\textbackslash #1}}
> >l.44 ... for the data from file \file{graph.dat}.}
> >
> >?
> >! Emergency stop.
> >\filenq #1->{\py@smallsize \textsf {\let \e
> >                                            =\textbackslash #1}}
> >l.44 ... for the data from file \file{graph.dat}.}

I do not understand this either, but I had the same problem.
Strange enough, if you define \e in any way, either using \def or

  \let\e=\textbackslash

at the beginning of graph.tex, there is no error anymore, and
everything works.

> Removing the \file{} macro from the caption on line 44 solved the  
> problem, and the compilation of the manual completes successfully.  
> However, not having found where the definition for the  \file{} macro  
> is located, I wasn't be able to understand the real reason of this  
> failure. Could you help me?
> 
> For sake of completeness here they are the specifications of my teTeX  
> distro:
> 
> >Totila:~ andrea$ latex --version
> >pdfeTeX 3.141592-1.20a-2.2 (Web2C 7.5.3)

you are using pdftex as default engine. Did you have to change
manual.cls also? See the python bug report on this
http://sourceforge.net/tracker/index.php?func=detail&aid=1238210&group_id=5470&atid=105470

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

[PyX-devel] Problems building manual.pdf

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

Hi all,
I was trying to build the PyX release 0.8.1 when I noticed that the  
manual.pdf file didn't build correctly. It turned out that the  
problem was twofold. First the manual/Makefile has got an error and  
here it is the patch:

> *** /Users/andrea/Installs/Python/PyX-0.8.1/manual/Makefile.orig    
> Tue Sep  6 16:43:38 2005
> --- /Users/andrea/Installs/Python/PyX-0.8.1/manual/Makefile     Tue  
> Sep  6 16:46:43 2005
> ***************
> *** 22,28 ****   
> pdf:manual.pdf                                                         
>                                         html:manual/manual.html
> ! manual.pdf: $(src)
>         #for index-with-own-hyperrefs debugging, anybody interested?
>         #./mkhowto --a4 --pdf --keep manual.tex
>         ./mkhowto --a4 --pdf manual.tex
> --- 22,28 ----
>   pdf:manual.pdf
>   html:manual/manual.html
>
> ! manual.pdf: $(src)  
> eps                                                                    
>                            #for index-with-own-hyperrefs debugging,  
> anybody  
> interested?                                                  #./ 
> mkhowto --a4 --pdf --keep  
> manual.tex                                                             
>            ./mkhowto --a4 --pdf manual.tex

The second problem is more subtle and I haven't understood it  
completely. After patching the Makefile as show above, the  
compilation of the manual fails while processing graph.tex with the  
following error message:

> ! Undefined control sequence.
> \filenq #1->{\py@smallsize \textsf {\let \e
>                                             =\textbackslash #1}}
> l.44 ... for the data from file \file{graph.dat}.}
>
> ?
> ! Emergency stop.
> \filenq #1->{\py@smallsize \textsf {\let \e
>                                             =\textbackslash #1}}
> l.44 ... for the data from file \file{graph.dat}.}

Removing the \file{} macro from the caption on line 44 solved the  
problem, and the compilation of the manual completes successfully.  
However, not having found where the definition for the  \file{} macro  
is located, I wasn't be able to understand the real reason of this  
failure. Could you help me?

For sake of completeness here they are the specifications of my teTeX  
distro:

> Totila:~ andrea$ latex --version
> pdfeTeX 3.141592-1.20a-2.2 (Web2C 7.5.3)
> kpathsea version 3.5.3
> Copyright (C) 1997-2004 Peter Breitenlohner (eTeX)/Han The Thanh  
> (pdfTeX).
> Kpathsea is copyright (C) 1997-2004 Free Software Foundation, Inc.
> There is NO warranty.  Redistribution of this software is
> covered by the terms of both the pdfeTeX copyright and
> the GNU General Public License.
> For more information about these matters, see the files
> named COPYING and the pdfeTeX source.
> Primary author of pdfeTeX: Peter Breitenlohner (eTeX)/Han The Thanh  
> (pdfTeX).
> Kpathsea written by Karl Berry and others.

Thanks,
  Andrea.

[PyX-devel] $B$[$$"v%W%l%<%s%H$@$h$)(B

[<in...@ya...>]

　◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇

残暑にも負けずランランラン♪KING☆

　http://merutomo.1192296.net/ranran.html

【解禁】リアルな女の子の写メールも一挙公開だじょぉ♪

　http://merutomo.1192296.net/ranran.html

今日中に早食いしたいヒトにはオイシイかも！？《笑》

　http://merutomo.1192296.net/ranran.html

　◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇


拒否はこちら
　ky...@de...

.

Re: [PyX-devel] a question on method arguments

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

Hi,

On 01.09.05, se...@so... wrote:
> I would like to ask you whether the following "feature" could be 
> implemented 
> in pyx. Currently, things like colour, style etc. are given to methods in 
> a list
> (such as [color.rgb.blue] in
> c.fill(union, [color.rgb.blue])
> taken from one of your examples)
> 
> What do you think about allowing (e.g.)
> c.fill(union, color.rgb.blue)? (it is just that sometimes there are too 
> many brackets, so it might be good to get rid of the frequent [,]). 
> Naively it should require just replacing
> 
> def fill(..., list_of_args=[]):
>     ...
> 
> with
> 
> def fill(..., *list_of_args):
>     if len(list_of_args) is 1 and isinstance(list_of_args[0],list):
>         list_of_args=list_of_args[0]
>     ...
> 
> 
> but I imagine in real life things are more complicated.
> Anyway, I'd be glad for your opinion.

Thanks for your suggestion. I should tell you, that in earlier
versions we had such an automatism and at some point we dropped it!

Let me briefly explain you why: There are frequently cases, where we
do have not just a single attributes list accepted by the
method/constructor/etc. Still, one could think of such an automatism.
Suppose you have something like:

    def arrow(styles=[], length=1*unit.v_cm):
        ...

Currently you could use it by:

    arrow(styles=[style1, style2])

but also by

    arrow([style1, style2])

(The point is, that Python allows you to omit the keywords, when using
the arguments in the order they are defined.) Suppose we do such an
automatism. Than you could do:

    arrow(styles=[style1, style2])
    arrow(styles=style1)
    arrow(style1)

but the following would fail with a very strange error message:

    arrow(style1, style2)

So the whole point is, that you could easily forget the brackets.
That's why we started at all places, where from the design point of
few, we do want to be able to handle several distinct arguments.

You may have a look to the mailing list archive ... about 1 1/2 years
ago. There was quite some discussion about it which all the pro's and
con's ...


André

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

[PyX-devel] a question on method arguments

[<se...@so...>]

Hello,

I would like to ask you whether the following "feature" could be 
implemented 
in pyx. Currently, things like colour, style etc. are given to methods in 
a list
(such as [color.rgb.blue] in
c.fill(union, [color.rgb.blue])
taken from one of your examples)

What do you think about allowing (e.g.)
c.fill(union, color.rgb.blue)? (it is just that sometimes there are too 
many brackets, so it might be good to get rid of the frequent [,]). 
Naively it should require just replacing

def fill(..., list_of_args=[]):
    ...

with

def fill(..., *list_of_args):
    if len(list_of_args) is 1 and isinstance(list_of_args[0],list):
        list_of_args=list_of_args[0]
    ...


but I imagine in real life things are more complicated.
Anyway, I'd be glad for your opinion.
Best regards
Paul

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Hi,

On 31.08.05, Joerg Lehmann wrote:
> > Jörg:    - brace should be a path (highly parameterized)
> >            --> put them into new path construction package
> >          - not a path decorator (not appliable to arbitrary paths)
> > André:   - in the first, they are path "constructors"
> >            rather path creators than decorators
> 
> Actually this was exactly what I meant: there should be a separation
> between something which creates a path based on certain parameters and
> some other thing which does this for a given path. The latter thing is
> typically based on the former. This means that there might be two
> versions of nearly the same thing at different places. I think that
> André fully agrees with me, here.

Right.

> > Magnus:  - braces for arbitrary paths
> 
> This is indeed a bit different, as it probably requires something much
> more general. If this were implemented, it would be a decorator. But the
> current code is clearly different, so this is quite hypothetic.

Just as a side remark: we can also build quite some braces (but not
intrinsically curved as Michaels braces are) out of some straight
lines and some smoothing. So we could also build a brace for this
case.

> > Thus, I still do not know where to put the braces. But that is no
> > problem to me. At the moment, I think they would fit best in the
> > connector module, but this is only because the connectors are not well
> > integrated between paths, decorators and boxes, anyhow.
> 
> As I wrote somewhere in one of my mails, I think this would certainly
> an option for the moment, i.e., in the present scheme.
> 
> > Maybe it is best to wait until we have found/created a proper place
> > for them?
> 
> +1  :-)

I would prefer that for the moment as well. We might soon split the
path and the normpath, just because this is much less questionable.
For the path construction functions (derived classes, whatever), we
can easily decide later ...


André

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

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Hi Michael!

On 31.08.05, Michael Schindler wrote:
[snip]
> This has been quite a contrary discussion now, and I think it needs a
> summary. I have collected some of the main statements (hopefully)
> 
> Jörg:    - brace should be a path (highly parameterized)
>            --> put them into new path construction package
>          - not a path decorator (not appliable to arbitrary paths)
> André:   - in the first, they are path "constructors"
>            rather path creators than decorators

Actually this was exactly what I meant: there should be a separation
between something which creates a path based on certain parameters and
some other thing which does this for a given path. The latter thing is
typically based on the former. This means that there might be two
versions of nearly the same thing at different places. I think that
André fully agrees with me, here.

>          - decorators for straight lines only
> Michael: - should derive from something "alignable"

They still could do so, but as just said it's quite probable that you
can implement this quite easily on top of your current code. 

> Magnus:  - braces for arbitrary paths

This is indeed a bit different, as it probably requires something much
more general. If this were implemented, it would be a decorator. But the
current code is clearly different, so this is quite hypothetic.

> Thus, I still do not know where to put the braces. But that is no
> problem to me. At the moment, I think they would fit best in the
> connector module, but this is only because the connectors are not well
> integrated between paths, decorators and boxes, anyhow.

As I wrote somewhere in one of my mails, I think this would certainly
an option for the moment, i.e., in the present scheme.

> Maybe it is best to wait until we have found/created a proper place
> for them?

+1  :-)

        Jörg

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

[Michael S. <m-s...@us...>]

Hello,

On 31.08.05, Andre Wobst wrote:
> On 31.08.05, Joerg Lehmann wrote:
> > On 31.08.05, Michael Schindler wrote:
> >
> > > Two points + orientation sign are sufficient to orient a brace.
> > > Next, the brace yields one point + orientation vector for aligning
> > > something to the brace (some text, some connectors, another brace?)
> > > It should also be possible to align a brace the other way round:
> > > one point + orientation vector --> Two points + orientation sign
> > 
> > Ok, this would imply that there are different factory methods for a
> > brace (in fact there already is one, namely straightbrace). But that's
> > no problem.

This is not the point I meant. You are totally right if you say that a
brace is a highly parameterized path -- But a function graph, plotted
from graph.graphxy.plot is also a highly parameterized path.

When I draw a brace, say on a poster, grouping some figures in order
to write text to them, I do not mind if this brace is a path, I want
to give it the corner points of the figure group and then want to ask
it where I should place my text. This is the alignment aspect I spoke
of.
I admit, this aspect is rather in the visionary context of André's
boxes.

> Also a brace decorator build out of a brace factory living in paths
> can additionally hide some of the complicated internal parametrization
> by some simplification of the usecase. That's good news, not bad one.

Yes.

> > > The boxes, when I have understood André right, should orient
> > > themselves relative to other boxes, too. Their orientation relative to
> > > one point + orientation vector is already there.
> > > 
> > > The connectors, on the other hand, need more information than just
> > > points. They only work if they also have some distance information
> > > (for cuts at their ends), so I have chosen boxes (point + outline
> > > path) to be the alignment base for the connectors.
> > 
> > Ok, but still they yield a path, no matter what things you use to build
> > them [1]. Btw, that's why the connectors module should probably also be
> > moved into a "paths" package.
> 
> I don't think so. Connectors are connecting boxes and take into
> account a box center (or whatever this will become in the future) and
> the box boundary.

I agree with André.

> However, there might be quite some basic path
> creators in the paths module, which help to construct those paths. An
> great example would be the bezier curves created from the end points,
> the tangents and the curvatures, which is currently hidden somewhere
> in the deformer ... where it really doesn't belong to.

+1 from me.

> > > When seen from their path capability the braces are rather like
> > > decorators. One decorates something (a path, a box, ...) with a brace,
> > > similar to the arrow heads.
> > 
> > Really? It didn't seem to be like that, at least at the moment. And how
> > do you want to decorate an arbitrary path with a brace. I don't think
> > this makes sense. On the other hand, arrow heads could go into such a
> > module (but not the arrows decorators).

I neither want to decorate arbitrary paths with a brace. Whenever I
draw a brace (by hand on paper) I draw it to cling to a straight line.
The arbitraryly curved brace -- beside the problems with the parallel
deformer -- seem to be over-designed.


This has been quite a contrary discussion now, and I think it needs a
summary. I have collected some of the main statements (hopefully)

Jörg:    - brace should be a path (highly parameterized)
           --> put them into new path construction package
         - not a path decorator (not appliable to arbitrary paths)
André:   - in the first, they are path "constructors"
           rather path creators than decorators
         - decorators for straight lines only
Michael: - should derive from something "alignable"
Magnus:  - braces for arbitrary paths

Thus, I still do not know where to put the braces. But that is no
problem to me. At the moment, I think they would fit best in the
connector module, but this is only because the connectors are not well
integrated between paths, decorators and boxes, anyhow.
Maybe it is best to wait until we have found/created a proper place
for them?

Michael.

-- 
"A mathematician is a device for turning coffee into theorems"
  Paul Erdös.

[PyX-devel] $B$+$*$j$A$c$s$K(B2 $BEYL\$NCf$@$7$J$N$@!*!*(B

[<in...@ya...>]

　　http://free-deai.1192296.net/oldlog/20050728.php

相変わらず出会い系サイトにドップリの小次郎です！
今日は29歳のOL、かおりちゃんとエッチしてきたのだ！。
7月終わりに出会って以来、2度目のデートなのだ。
相変わらずスタイル抜群で、大人の魅力全開！

　　http://free-deai.1192296.net/oldlog/20050728.php

今日も、前回と同様にホテルに直行！
さすがセフレは話が早いね！
またまた中出ししちゃったよー！
中出しサイコー！かおりちゃんサイコー！！
エッチの後は食事をご馳走になったのだ！！
ダブルでご馳走様でした！！

　　http://free-deai.1192296.net/oldlog/20050728.php

拒否はこちら。
 　 ky...@de...

.

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Hi,

On 31.08.05, Magnus Lie Hetland wrote:
> I have only looked at the source for the arrows (implemented my own
> bent arrows in MetaPost at one time, to get sharp points :)... But
> here is the package, anyway:
> 
>   http://www.student.nada.kth.se/~f91-tek/cm_arrows.html

Thanks for this link. Quite interesting.

> I've used the brace code. One nice thing is that you can place the
> middle "notch" (or whatever) wherever you want along the path.

Yes, Michael's code can do that as well. It also allows you to tilt
the middle notch ... ;-)

> Hm. Perhaps the arrow code could be useful too? After all, if we
> typeset text with TeX, having arrows that look consistent with the
> arrows in Computer Modern may not be a bad thing. (Perhaps a really
> parametrizable arrow class -- so the CM style could just be a special
> case?)

Right. At some point we could invest some time in makeing TeX-style
braces and arrows to better fit the computer modern style. Meanwhile
we do have arrows and we do have serveral solutions for braces,
especially some which are completely (but weakly) curved when used
along a straight line ... which looks quite nice.

So this tells us, that (at least some) braces fit into the concept of
decorators for arbitrary paths. Hence they could be implemented to be
decorators and nothing else. Still it seems natural, that there are
some brace-path-creation facilities, which are available as plain path
constructors/creators/factories (whatever you name it). Especially
Michaels curved braces, which are (currently?!;-)) available for a
straigh "baseline" only, do better fit to be a path creator than to be
a decorator. It could live in a newly created paths module, where for
the sake of uniformity things like path.circle and path.rect should be
moved into as well.


André

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

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Joerg Lehmann <jo...@us...>:
>
> Hi Magnus!
> 
> On 31.08.05, Magnus Lie Hetland wrote:
[snip]
> > There is a package with braces for MetaPost that lets you do curved
> > braces. 
> 
> Has anybody looked at this package.

I have only looked at the source for the arrows (implemented my own
bent arrows in MetaPost at one time, to get sharp points :)... But
here is the package, anyway:

  http://www.student.nada.kth.se/~f91-tek/cm_arrows.html

I've used the brace code. One nice thing is that you can place the
middle "notch" (or whatever) wherever you want along the path.

Hm. Perhaps the arrow code could be useful too? After all, if we
typeset text with TeX, having arrows that look consistent with the
arrows in Computer Modern may not be a bad thing. (Perhaps a really
parametrizable arrow class -- so the CM style could just be a special
case?)

-- 
Magnus Lie Hetland
http://hetland.org

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Hi,

On 31.08.05, Joerg Lehmann wrote:
> Btw: I'd really like to get comments on this issue from other people,
> as well, especially since most PyX users would be affected if we adopt
> such a new hierarchy

Hmm!

> On 31.08.05, Michael Schindler wrote:
> > Two points + orientation sign are sufficient to orient a brace.
> > Next, the brace yields one point + orientation vector for aligning
> > something to the brace (some text, some connectors, another brace?)
> > It should also be possible to align a brace the other way round:
> > one point + orientation vector --> Two points + orientation sign
> 
> Ok, this would imply that there are different factory methods for a
> brace (in fact there already is one, namely straightbrace). But that's
> no problem.

Also a brace decorator build out of a brace factory living in paths
can additionally hide some of the complicated internal parametrization
by some simplification of the usecase. That's good news, not bad one.

> > The boxes, when I have understood André right, should orient
> > themselves relative to other boxes, too. Their orientation relative to
> > one point + orientation vector is already there.
> > 
> > The connectors, on the other hand, need more information than just
> > points. They only work if they also have some distance information
> > (for cuts at their ends), so I have chosen boxes (point + outline
> > path) to be the alignment base for the connectors.
> 
> Ok, but still they yield a path, no matter what things you use to build
> them [1]. Btw, that's why the connectors module should probably also be
> moved into a "paths" package.

I don't think so. Connectors are connecting boxes and take into
account a box center (or whatever this will become in the future) and
the box boundary. However, there might be quite some basic path
creators in the paths module, which help to construct those paths. An
great example would be the bezier curves created from the end points,
the tangents and the curvatures, which is currently hidden somewhere
in the deformer ... where it really doesn't belong to. Still it's
controversal, whether this is really something we want to have in the
paths module, since its just another parametrization to create a
bezier pathitem. OTOH all allowed pathitems are defined in the path
module and the path module should not grow to something with
complicated numerical stuff in. A solution would be a pathitems module
as well, but no ... this is would be strange too. And the bezier path
constructed out of the end points and some restrictions is a real path
... it clearly has a starting point.

> Really? It didn't seem to be like that, at least at the moment.

I think building a brace along an arbitrary path will be quite
difficult. The best you could do (and maybe that's an option), would
be to use the parallel deformer, add some small line segments and run
a smoother on top of it. Its not that good as a real curved brace, but
its actually not that bad, as we've recently learned (especially after
our smoother rework we did last weekend). So still, may be a brace
along an arbitrary path is not that unlikely to be constructable.

> And how
> do you want to decorate an arbitrary path with a brace. I don't think
> this makes sense. On the other hand, arrow heads could go into such a
> module (but not the arrows decorators).

Right. The arrow head path construction could go into a paths module.


André

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

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Hi Magnus!

On 31.08.05, Magnus Lie Hetland wrote:
> Andre Wobst <wo...@us...>:
> >
> [snip]
> > Basically braces are decorators for me. But they can decorate
> > straight lines only.
> 
> There is a package with braces for MetaPost that lets you do curved
> braces. 

Has anybody looked at this package.

> Not sure how useful that is, but if braces are to be path
> decorators, it might be consistent to let them apply to all paths?

Exactly. And as long as this is not possible, we should not call them
path decorators.

        Jörg

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

On 31.08.05, Andre Wobst wrote:
> On 31.08.05, Michael Schindler wrote:
> > This is worth to be considered. But the geometry elements like line,
> > circle, rect,... are far more basic than a brace. A brace makes no
> > sense to me without aligning things to it. We have a similar problem
> > as with the boxes and the connectors:
> > 
> > Two points + orientation sign are sufficient to orient a brace.
> > Next, the brace yields one point + orientation vector for aligning
> > something to the brace (some text, some connectors, another brace?)
> > It should also be possible to align a brace the other way round:
> > one point + orientation vector --> Two points + orientation sign
> 
> Well, isn't this whole discussion about *using* braces for example as
> decorators to lines or connectors between boxes.

Exactly: using.

> > The boxes, when I have understood André right, should orient
> > themselves relative to other boxes, too. Their orientation relative to
> > one point + orientation vector is already there.
> > 
> > The connectors, on the other hand, need more information than just
> > points. They only work if they also have some distance information
> > (for cuts at their ends), so I have chosen boxes (point + outline
> > path) to be the alignment base for the connectors.
> > 
> > So, when introducing braces in a geometry package we certainly should
> > derive them from a class that can align (boxes?)
> > 
> > When seen from their path capability the braces are rather like
> > decorators. One decorates something (a path, a box, ...) with a brace,
> > similar to the arrow heads.
> 
> Basically braces are decorators for me. But they can decorate straight
> lines only. 

If they can only do this, then they are neither deformers nor
decorators.

> They could also be used to decorate connection lines
> between boxes. 

In this sense they are connectors. So one alternative option would
be to put them in the connectors module.

> Something like this ... but I'm not sure. However, a
> brace decorator would basically place some text (or different canvas,
> say a box) as a description text (or whatever). There might be cases,
> where you want to use braces directly without constructing a
> connection line to be decorated. I'm not that sure either, but I think
> so.

You can certainly do more stuff, but the basic thing is a highly
parametrized path.

        Jörg

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Hi André,

On 31.08.05, Andre Wobst wrote:
> I was always thinking about braces to be somehow related to connectors
> and/or decorators. But neigher connectors nor decorators fit very
> well. Instead, in the first, they are path "constructors". A
> brace-function seems absolutely natural. I have to repeat myself: +1

Exactly. Don't be to focused on decorators and this whole stuff. It's a
good framework and terminology for some things but definitely not for
everything.

> > We could then create a new package
> > (for instance "paths", but I'm sure there is a better name, "elements"
> > also came to my mind) which contains only modules generating paths. In
> > principle, already a simple circle or a line would belong there, but I'm
> > not sure whether we want something like:
> > 
> >         paths.circle.circle(1, 2, 3)
> >         paths.line.line(1, 2, 3, 4)
> > 
> > One could also think about grouping stuff together
> > 
> >         paths.basic.circle(1, 2, 3)
> >         paths.basic.line(1, 2, 3, 4)
> > 
> > Then we could also say that all stuff from the basic package is so
> > important that we inject it in the paths namespace:
> > 
> >         paths.circle(1, 2, 3)
> >         paths.line(1, 2, 3, 4)
> > 
> > Actually, I think this is not too bad, is it?
> 
> Interesting. But it looks a bit overdesigned. Should paths become a
> subdirectory? How is this subdirectory related to the path (normpath)
> module(s)? Do we except such a huge number of path creating functions
> having that much code? Get's something like a -0.5 from me ...

Ok, but if we move the connectors there (which makes a lot of sense) and
have braces there as well, we certainly don't want to put everything
into one file.

> I would suggest to split the path module into path, paths and
> normpath (the later is quite unimportant to the user, it should not
> even be imported by "from pyx import *").

Of course.

> > Btw, André, if we are about to split path anyway (in order to separate
> > normpath out), we could also think about doing things like this at the
> > same time.
> 
> BTW I've already started to rework the pathitem signature. It seems to
> work very well and leads to very clean and readable code (overall it
> becomes less code and faster code as well). However, I'm not yet
> finished (pdf is not working ... I want to allow for epsilon=None to
> be used in that case), but I guess I can easily finish it tonight.
> It's not really related to this discussion, but I could easily split
> of the normpath (a regular user should not even notice this) ... and
> create a paths module at the very same time. Do we already have a
> consensus (otherwise this splitting can wait ... as I said, its not
> really related).

Let's first do one thing and split later.

        Jörg

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

On 31.08.05, Andre Wobst wrote:
> Splitting of the paths (circle, rect, etc. seems natural), when we
> deside to allow for complicated path creators like the braces. As I
  decide
> said, its kind of 

... unfinished. Ops. ;-)

I currently see advantages of allowing complicated path constructors
in a paths module. Hence I support Jörgs idea for a split of the path
module into three parts.


André

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

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Andre Wobst <wo...@us...>:
>
[snip]
> Basically braces are decorators for me. But they can decorate
> straight lines only.

There is a package with braces for MetaPost that lets you do curved
braces. Not sure how useful that is, but if braces are to be path
decorators, it might be consistent to let them apply to all paths?

-- 
Magnus Lie Hetland
http://hetland.org

Re: [PyX-devel] Re: [PyX-checkins] pyx/test/experimental brace.py,NONE,1.1

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

Hello Michael!

Btw: I'd really like to get comments on this issue from other people,
as well, especially since most PyX users would be affected if we adopt
such a new hierarchy

On 31.08.05, Michael Schindler wrote:
> On 31.08.05, Joerg Lehmann wrote:
> > On 31.08.05, Michael Schindler wrote:
> 
> > Looks amazing! But obviously, we do not yet have a place where one could
> > put such stuff. Maybe it would maybe be more clear if brace were a path
> > instead of having a path() method.
> 
> Oh, this can easily be changed -- it is of no importance.

Fine.

> > We could then create a new package
> > (for instance "paths", but I'm sure there is a better name, "elements"
> > also came to my mind) which contains only modules generating paths. In
> > principle, already a simple circle or a line would belong there, but I'm
> > not sure whether we want something like:
> > 
> >         paths.circle.circle(1, 2, 3)
> >         paths.line.line(1, 2, 3, 4)
> > 
> 
> >         paths.circle(1, 2, 3)
> >         paths.line(1, 2, 3, 4)
> > 
> > Actually, I think this is not too bad, is it?
> 
> This is worth to be considered. But the geometry elements like line,
> circle, rect,... are far more basic than a brace.

Of course they are far more basic, but does that really matter?

> A brace makes no
> sense to me without aligning things to it. We have a similar problem
> as with the boxes and the connectors:

Hmm, but this is a different issue - which seems to be rather orthogonal
to the one at hand.

> Two points + orientation sign are sufficient to orient a brace.
> Next, the brace yields one point + orientation vector for aligning
> something to the brace (some text, some connectors, another brace?)
> It should also be possible to align a brace the other way round:
> one point + orientation vector --> Two points + orientation sign

Ok, this would imply that there are different factory methods for a
brace (in fact there already is one, namely straightbrace). But that's
no problem.

> The boxes, when I have understood André right, should orient
> themselves relative to other boxes, too. Their orientation relative to
> one point + orientation vector is already there.
> 
> The connectors, on the other hand, need more information than just
> points. They only work if they also have some distance information
> (for cuts at their ends), so I have chosen boxes (point + outline
> path) to be the alignment base for the connectors.

Ok, but still they yield a path, no matter what things you use to build
them [1]. Btw, that's why the connectors module should probably also be
moved into a "paths" package.

> So, when introducing braces in a geometry package we certainly should
> derive them from a class that can align (boxes?)

You can do that, but I think that's a different issue.

> When seen from their path capability the braces are rather like
> decorators. One decorates something (a path, a box, ...) with a brace,
> similar to the arrow heads.

Really? It didn't seem to be like that, at least at the moment. And how
do you want to decorate an arbitrary path with a brace. I don't think
this makes sense. On the other hand, arrow heads could go into such a
module (but not the arrows decorators).

> > Btw, André, if we are about to split path anyway (in order to separate
> > normpath out), we could also think about doing things like this at the
> > same time.
> 
> What is then to remain in path? Only the pathels?

Basically only the path class and the pathels. But that's enough.

        Jörg

[1] The only exception here would be to be the case of a deformator,
which constructs a new path out of a given one.