Re: Obtaining bounding box for glyphs

Thomas,

Thomas DeWeese wrote:

>    Why do you need glyph bounding boxes?  Normally text layout is done
> using the font ascent, descent and advance - these are all easily
> accessible from the font-face element (ascent, descent) and
> the individual glyph elements (horiz-adv-x).  I suppose in mathML
> layout there may be some reason you want to know the true glyph
> geometry bounds, but this seems very suspect to me.

Well, here are some typical situations when it is desirable to know
the actual bounding box:

    - when you draw a root sign around a character whose vertical extent
      exceeds the ascender of the font, you typically raise the upper bar
      of the sign, so as to avoid intersection with the glyph;

    - when you put a 'p' character into an enumerator of a fraction, you
      typically place it higher than the 'a' character, so that its leg
does
      not cross the fraction line;

    - when you draw an italic 'f' character followed by a prime, you
      normally want the prime to be positioned at the right of 'f'.
      Because of the upper swash, the character protrudes quite
      significantly to the right of its advance width; if you don't use
      bbox data, you end up drawing the prime on top of the 'f';   

I am not alone in using these data. Just compare 'a/c' fraction to 'p/d';
in many typesetting systems, you'll notice the difference in baseline
positioning.

>    I think the BBox is intended to be calculated using the
> advance, ascent, descent.  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.

No chance. Consider a superscript 0 added to the cursive 'f': unless
I correct the distance between them using bbox, the superscript
overlaps with the upper swash of 'f'. No kerning table can ever help here -
font variant, font size, and baseline position are all different between
the two characters.

Let me repeat my initial point: I am a bit perplexed that a piece of useful
functionality is present in all major font metric formats - except SVG.
If SVG WG dropped it, they did it for a purpose; may I know the purpose?
And what's the suggested alternative method to make these data
available to an application that does not have an SVG renderer?

Regards,
Nikolai Grigoriev

Received on Friday, 10 June 2005 11:37:01 UTC