Re: Obtaining bounding box for glyphs

Hi Jon,

    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 (what
happens when the bbox data doesn't match the real char?).

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

    Nikolai a possible solution that might be more palatable
than generating an AFM file would be to rewrite the SVG font
to include a bbox attribute in a custom namespace.  The
"problem" is that you are trying to make sense of an SVG
document without an SVG implementation to support you.

Jon Ferraiolo wrote:
> As I remember historical discussions about text APIs within the SVG 
> working group, we recognized the value for some content developers to 
> have APIs which would provide bounding boxes for glyphs (versus 
> characters, which includes the full character cell independent of the 
> glyph that is used), but considered this an extra feature which was 
> deemed not to have a high-enough priority to justification including 
> such APIs in SVG 1.0, 1.1, or even SVG 1.2 (at least so far). At this 
> stage, I would expect the SVG working group to be resistant to adding 
> these APIs to any version of SVG 1.2 (Tiny or Full) since the focus is 
> finishing the spec, not adding more features.
> 
> Jon
> 
> At 04:53 AM 6/10/2005, Boris Zbarsky wrote:
> 
>> Thomas DeWeese wrote:
>>
>>> I suppose in mathML layout there may be some reason you want to know 
>>> the true glyph
>>> geometry bounds
>>
>>
>> If nothing else, you absolutely need glyph geometry bounds to get 
>> reasonable-looking superscripts and subscripts (this requires knowing 
>> the ascent and descent of individual glyphs).
>>
>> Note that there are other reasons one might want to know bounding 
>> boxes even in a non-MathML context; doing drop-caps well requires that 
>> information, for example.
>>
>>>    I think the BBox is intended to be calculated using the
>>> advance, ascent, descent.
>>
>>
>> That doesn't work.  For example, if you have a standard English font 
>> the bounding box this procedure would give for an "x" would extend as 
>> far below the baseline as the one for a "g" (Since the ascent/descent 
>> are per-font-face, not per-glyph).
>>
>>> If you want to do a really good job
>>> you should also look at the hkern elements which will adjust the
>>> horiz-adv-x based on text context.
>>
>>
>> That doesn't help with the vertical issues, though.
>>
>> -Boris
>>
>

Received on Friday, 10 June 2005 19:30:24 UTC