- From: Jon Ferraiolo <jon.ferraiolo@adobe.com>
- Date: Fri, 10 Jun 2005 13:49:06 -0700
- To: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, Nikolai Grigoriev <grigoriev@comtv.ru>, www-svg@w3.org
Thomas, Another option to consider for the future is some sort of "convert to graphics" method which takes a text string, creates a new subtree consisting of <g> and <path> elements (one path for each glyph), and then you can call getBBox() on that subtree or its subelements. While this approach is clunky, I see lots of problems if we attempt to add APIs which require interaction with the underlying font engine, which might have sufficient APIs for these kinds of queries and which might be doing all sorts of funky things under the hood when operating on text objects, such as antialiasing, glyph shifting to align on pixel boundaries, and various other adjustments based on font hints. Jon At 12:30 PM 6/10/2005, Thomas DeWeese wrote: >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 20:49:25 UTC