[metapost] workaround for turningnumber bug
luecking at uark.edu
Mon Jan 31 19:48:56 CET 2005
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.
Daniel H. Luecking
Department of Mathematical Sciences
University of Arkansas
More information about the metapost