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

[Ivan Nincic]

> > > I don't deny that the current code has some problems. For example,
Werner
> > > seems to think that the arc stack can overflow.
>
> > I don't `think'.  This was a bug report. :-)
>
> Check out my original bug report. I included a case in which path
overflowed
> existing stack by several orders of magnitue.  For any fixed stack there
is a
> Bezier which will overflow it.
-
>Is the original report on sourceforge?  Do you 
>have a sample font that causes problems?  If so, 
>I'd have to say the font is not "good" in the sense of
>following the Type 1 recommendations that start/end 
>points of arcs are at points of horizontal of vertical 
>extrema (this means that the tangents at these points
>are horizontal or vertical -- from one's basic calculus).  
>If this is the case,the bbox code *should* work just fine 
>after David makes the change he said he would make).
>
>If this is not the case, I'd like to understand way the 
>iterations exceed the arc stack (and by how much).  David's 
>changes will allow for up to 32 interations.
-

I wanted to use FT_Outline_Get_BBox for arbitrary Bezier curves. If Type1
spec has such a restriction then stack overflow may never occur (is there a
proof for this?). Does TT and all other supported and will-be-supported
fonts have the same restriction. If yes than this should be documented in
the source code or header files. 

Here is my original 'bug'-report (proto.cpp is using OS stack which may also
be
overflowed, but allows for more than 32 iterations):

Ivan

-
>Subject: Re: FT_Outline_Get_BBox
>Date: Fri, 03 Nov 2000 12:28:49 -0800
>From: Ivan Nincic <address@hidden>
>
>BBox_Cubic_Check is crashing for many curves because of the small stack
>size (33).
>
>Here is an example :
>MoveTo: 408.9111, 535.3164
>CurveTo :455.8887, 634.396, -37.8765, 786.2207, 164.6074, 535.3164
>
>Attached is the sample PDF file.
>
>Does anybody knows what would be the largest stack size given an
>arbitrary Bezier curve?
>I will look into this ... If the stack is too large we should probably
>look at some other algorithm.
>
>Ivan
>
> > I have couple of questions related to FT_Outline_Get_BBox.c
> > 1)
> >  if ( y1 == y4 ) {
> >   if ( y1 == y2 && y1 == y3 ) {     /* Flat */
> >           y4 = y1;           // 236
> >          goto Test;
> >   }}
> >
> > Is the assignment on line 236 some kind of coding style or is it
> > redundant?
>
> Redundant :-)  I've fixed it.
>
> > 2)
> > BBox_Cubic_To() and BBox_Conic_To() callback never update the
> > user->last point (as BBox_Move_To() does). Does this mean that two
> > consecutive Beziers may have a wrong bbox ?
>
> It's a bug also.
>
> Thanks for the report.
>
>     Werner

sample.pdf
Description: Binary data

Proto.cpp
Description: Binary data