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

[Tom Kacvinsky]

Hi Just,

>
> 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...

Now, I know TTX will do what I want when I get around to it, but what about
ttf2afm?  It uses the bbox code for extracting bbox info from a TTF.  What
will happen when the code is extended to support OpenType/CFF fonts?

I can't speak fo others uses, but that is why I am all for getting exact bbox
information. :)

> To me, an exact bbox is only "nice to have", and therefore performance can't 
> be
> an issue either. If performance is an issue, you can't beat the cbox! I don't
> believe that the cost of *always* calculating an exact bounding box weighs up
> against wasting some space in fairly uncommon cases. Non-conforming fonts? 
> Blame
> the font. Rotated text? I really wouldn't care if it were slightly slower.
>
> (Oh, and you can't crash a cbox function due to weird input...)
>

Right.  I agree with most of your points.  As for crashing due to weird input:
that is a problems with the code that can be fixed (and will be fixed).

Tom