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

[Ivan Nincic]

>> > But I don't understand *why* to *ever* worry about an exact bounding
box? If 
>> > the outlines are decent, the cbox is fine, and if the outlines are not
so 
>> > decent, then the cbox may be too large, but why should FT care?
>> 
>> I'll give you an example (and it shouldn't surprise you, considering the
topic
>> has been opened on the OpenType list):
>> 
>> Getting AFM data from OpenType/CFF fonts.  The AFM ought to have decent
glyph
>> bbox info for post processing by tools like afm2tfm, etc...
>
>Not knowing tfm's at all, so I have to ask: why isn't the cbox good enough
even
>for those purposes? (I just checked, the AFM spec indeed mumbles something
about
>"flattened paths", so strictly speaking you are absolutely right.)
>
>But this also proves my other point: for such tools speed is not an issue,
so a
>"simple" implentation using floats and sqrt's etc. would be good enough. No
need
>to fiddle with fixed point math, splitting curves, etc.

If you cache the box you may use it for more efficient interactive path
rendering. Larger invalidated box is worse because more graphics object may
have to be redrawn.
Also, I am using BBox in many cases that I can't talk about. 

Ivan