- From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Date: Fri, 10 Jun 2005 11:59:15 -0700
- To: Boris Zbarsky <bzbarsky@MIT.EDU>, Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Cc: Nikolai Grigoriev <grigoriev@comtv.ru>, www-svg@w3.org
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:19:27 UTC