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

[Tom Kacvinsky]

Hi Just,

On Tue, 24 Apr 2001, Just van Rossum wrote:

> Tom Kacvinsky wrote:
>
> >
> > >
> > > 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.)
>

We need accurate width, height, and depth for the glyphs to get a meaningful TFM
out of an AFM.  The reasons are myriad and are outlined in more detail in the
TeXbook by none other than D. E. Knuth.  Without accurate metrics, TeX is going
to typeset some pretty ugly things. :)

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

Well, there are other ugly issues involved with the parametric equations for
Bezier curves, and if they are going to be tackled, wouldn't it be nice if they
were taken care of in FT, instead of having each user of FT cook up there own
algorithms?  And most users are probably happy with the cbox, but it is nice to
have working bbox code in there (for those who nned to hook into it).

>
> > Now, I know TTX will do what I want when I get around to it,
>
> (Erm, all I support right now are cboxes ;-)
>

Uh oh! :)

Tom