W3C home > Mailing lists > Public > www-svg@w3.org > June 2005

Re: Obtaining bounding box for glyphs

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
Message-id: <6.1.1.1.2.20050610134224.040a9460@mailsj-v1.corp.adobe.com>

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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:30 GMT