- From: Nikolai Grigoriev <grigoriev@comtv.ru>
- Date: Fri, 10 Jun 2005 15:37:14 +0400
- To: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- CC: Nikolai Grigoriev <grigoriev@comtv.ru>, www-svg@w3.org
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