Re: [Devel] Problems with bbox code and cubic bezier curves

[Tom Kacvinsky]

I think I found the gotcha in BBox_Cubic_Check.  I need an example of a font 
where the
bbox code doesn't work to test my hypothesis, though.  Werner, do you have some 
sample
fonts?  If not, I think I can cook one up that trips up a problem...

The problem has to do with the path splitting code -- it's underlying 
assumption is that
the curves can eventually be split into either "ascending" or "descending" 
curves (I use
quotes because the curves may not really be ascending [or descending]).  I 
don't know of a
mathematical proof that this will always be the case, but supposing it is, will 
we get to
that case w/o exceeding the array bounds on the arc stack?  By a quick 
arithmetic check,
the arc stack will be consumed after 9 iterations.

Supposing that a cubic bezier may eventually be split up into a sequence of 
either
ascending or descending curves, the fix can be accomplished by either using 
alloc/realloc
or some such to grow the arc stack as necessary, or by using recursion (we have 
to have
the condition that a bezier arc can be split into either ascending or 
descending subarcs,
otherwise we will eventually consume the heap, or exceed stack space).

Whatever fonts cause problems with the bbox code, though, have to have *not* 
followed the
Type 1 guidelines for arc construction -- if the rules are followed [in 
particular, start
and end points placed at horizontal/vertical extremes], the curve can *always* 
be split up
into ascending/descending subarcs.

On Mon, 23 Apr 2001, Tom Kacvinsky wrote:

> I have been looking at the bbox code for cubic bezier curves.  Coorect me if I
> am wrong here, but the problems are in BBox_Cubic_Check, right?  Something 
> looks
> fishy there, and I will try to track it down...
>