[svg2] Text bbox calculations

Hi,

 From https://svgwg.org/svg2-draft/coords.html#BoundingBoxes:
[[
For text content elements, for the purposes of the bounding box  
calculation, each glyph must be treated as a separate graphics element. he  
calculations must assume that all glyphs occupy the full glyph cell. For  
example, for horizontal text, the calculations must assume that each glyph  
extends vertically to the full ascent and descent values for the font. An  
exception to this is when the ‘width’ or ‘height’ attribute has been  
specified on the ‘text’ element, in which case the element's content area  
is its bounding box.
]]

There's a typo in the second sentence, 'he' -> 'The'. The part about text  
elements looks like it's unintentionally(?) repeated in  
https://svgwg.org/svg2-draft/coords.html#ObjectBoundingBoxUnits:
[[
For ‘text’ elements, for the purposes of the bounding box calculation,  
each glyph is treated as a separate graphics element. The calculations  
assume that all glyphs occupy the full glyph cell. For example, for  
horizontal text, the calculations assume that each glyph extends  
vertically to the full ascent and descent values for the font.
]]

The bbox algorithm itself uses 'glyph cell' instead of 'full glyph cell'  
and it's unclear if these two terms are the same thing. I think we should  
try to avoid unnecessary repetition, and clearly mark informative  
paragraphs as such, so that in the end there's only one normative  
definition.

Now on to my questions. Some fontfaces have glyphs that extend outside the  
advance, e.g https://www.google.com/fonts/specimen/Bangers. See the letter  
'D' for example, load the page and select the text.

It's not 100% clear in the spec what a 'full glyph cell' is, but as an  
author I'd certainly expect that the geometry I see on screen should be  
accounted for in the bbox. However, it seems that's not the case in all  
browsers.

My questions:

1) is the x position of the 'full glyph cell' for any given glyph assumed  
to always be zero?
2) is the width of the 'full glyph cell' meant to be the advance? if so,  
how should overshooting parts be handled?

I'd like to get consensus for how to deal with these cases because they  
matter for how objectBoundingBox works on text.

I'm sure the discussion will expand to include questions like:

3) should the glyph bboxes be tight shape bboxes instead as for all other  
geometry?
4) do we need separate bboxes to use for hit testing and text selection?  
or should they all be the same?
Take the string 'Thg.' as an example, it would look quite odd if the  
selection background jumped up and down per glyph, and it would be very  
hard to select the dot if it used just the tightest bbox for hit testing.
5) should text-decorations also affect the bbox?
6) 'text-rendering' may affect the results, since hinting can distort the  
shapes. Should we make that explicit in the bbox calculation algorithm, or  
is that clear anyway?

I'd like to handle each question separately if possible, right now I'm  
mostly interested in getting the first two questions answered.

As a datapoint, see Freetype documentation for getting glyph bboxes (we  
should be clear on which variant is required):
http://www.freetype.org/freetype2/docs/reference/ft2-outline_processing.html#FT_Outline_Get_BBox
http://www.freetype.org/freetype2/docs/reference/ft2-glyph_management.html#FT_Glyph_Get_CBox


-- 
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group

Received on Tuesday, 11 March 2014 12:19:45 UTC