Re: [svg2] Text bbox calculations

On Thu, 13 Mar 2014 07:00:50 +0100, Nikos Andronikos  
<nikos.andronikos@cisra.canon.com.au> wrote:

> On 11/03/2014 11:18 PM, Erik Dahlström wrote:
...
>> 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.

Right.

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

Right.

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

How would you propose we fix this?

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

For text selection I'd agree that it's an implementation detail.

However https://svgwg.org/svg2-draft/interact.html#PointerEventsProp talks  
about 'character cells' for text element hit-testing. So it does matter  
(and the definition there should probably be updated to use 'full glyph  
cell' if that's what it is meant to mean).

It would be nice to be able to use actual glyph geometry for the  
hit-testing, but if we want this then I think it should be an explicit  
opt-in, because it's most likely going to be slower than what is currently  
in the spec. I think it would be mostly useful for when the text is mostly  
decoration, or uses a very large font-size. We do have "pointer-events:  
bounding-box".


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

Received on Thursday, 13 March 2014 08:44:16 UTC