Re: [svg2] Text bbox calculations

On 11/03/2014 11:18 PM, Erik Dahlström wrote:
> 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.
Or have negative advances. The glyph metrics that are stored in the font
should never be used to calculate the bound of a glyph. OpenType fonts
do include a bounding box, but this is rarely correct.
>
> 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.
Agree
>
> My questions:
>
> 1) is the x position of the 'full glyph cell' for any given glyph
> assumed to always be zero?
I'm not totally sure what is meant in the spec at the moment, but I
don't think so. Glyphs can extend to before their start position.
> 2) is the width of the 'full glyph cell' meant to be the advance? if
> so, how should overshooting parts be handled?
That seems to be the case at the moment. But it's not a good way to do
things, because as you say, overshooting parts aren't included.
>
> 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?
Probably. http://andronikos.id.au/select_gabriola.png
But does it matter for text selection and hit testing though? This is an
implementation detail and not something that should be in the spec I
would have thought.

I think (although I might be missing some instances here) the only
bounding box that needs to be  included in the spec is the one on the
text element that is accessible to the author, and that should include
the geometry of all glyphs in the element.

> 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
>
>
>

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 13 March 2014 06:01:21 UTC