Re: Obtaining bounding box for glyphs


>    Just to clarify the API to access this info already exists on
> the text content interface (getExtentOfChar).  This is really
> a request to add a bbox attribute to the glyph element that
> contains the tight bounding box of the glyph data.  From a
> data normalization point of view this is problematic 

The data normalization point of view implies that you treat 
SVG font as a glyph database - i.e. something that roughly 
corresponds to PFA/PFB in the world of legacy font 
formats. But fonts are more than glyph databases - 
they also specify a whole lot of metric data in a form 
accessible to application writers that don't have access 
to printer hardware. That's why AFM is always supplied
along with PFB for Type1 fonts.

> (what
> happens when the bbox data doesn't match the real char?).

Suppose you have filters in the glyph definition, and your 
character is blurred. Where does its bbox end? Wouldn't it 
be natural to permit the font designer to specify edges as he 
wants them to be?

> Also I did some poking and even in AFM the bbox data 
> appears to be optional.

Yes, the spec lets you skip them (though I have never seen 
a professional font without glyph BBox data in the AFM).
Why couldn't the same approach be followed in SVG? Let's
make 'bbox' of glyph elements optional.

I dare claim that the common usage in typography is to 
provide app writers with bbox data. SVG seems to part with 
the tradition. I wonder if data normalization is by itself a
sufficient reason for it.


Received on Thursday, 16 June 2005 01:31:09 UTC