[metapost] workaround for turningnumber bug

[Dan Luecking]

At 03:24 AM 1/30/2005, you wrote:
> > When I try your algorithm on this path:
> > path p;
> > p := (0,0) ..controls (48,-18) and (24,-18).. (72,0)
> >             ..controls (90,48) and (90,24).. (72,72)
> >             ..controls (24,90) and (48,90).. (0,72)
> >             ..controls (-18,24) and (-18,48).. cycle;
> >
> > it returns true (with res = -1080). But the path is clearly
> > counterclockwise.
>
>Thanks for the counterexample.  Is such a curve possible (this is,
>with a `reversed' order of the control points) in mpost if I don't
>specify the control points explictly?

Specifying the control points is common with programs that generate
bezier paths. If we preclude that, then I believe (but I haven't been
able to prove it) that Hobby's formula (MFbook, page 131) for deriving
controls from direction and tension values is designed to prevent it.

>  My algorithm can be improved by using only the
>directions of `P -> P+' and `Q- -> Q' and assuring that no
>self-intersection does happen.  Actually, I can drop the
>self-intersection constraint, simply insisting that the curve doesn't
>self-intersect (which must not happen in font outlines).
>
>Are there any errors in my assumptions?

I don't see any. At least I think that is a better approach.


Dan


Daniel H. Luecking
Department of Mathematical Sciences
University of Arkansas