Re: [svg2] Text bbox calculations

On 13/03/2014 7:43 PM, Erik Dahlström wrote:
> 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?
I would say use the glyph geometry =)

But I think it depends on the use case.
For example, for hit testing, would an author expect hit testing on text
to function as it would if that text were simply a path? e.g. a click in
the 'hole' of an 'o' wouldn't register?
I think often they would, but there would also be occasions where a
simple rectangle surrounding the text would be enough.

What about text on a path? The box surrounding all glyphs could be very
large and contain large areas with no text.

I think the following options would all be useful in the right situation:
- the rect surrounding all painted pixels in the string - equivalent to
the SVG bounding box for other shapes
- the union of each glyphs surrounding rect where the surrounding rect
for each glyph encompasses all painted pixels
- the path data for all glyphs in the string

>
> ...
>>> 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).
I knew there'd be more to it =)

A 'character cell' appears to be the em square. See
http://lists.w3.org/Archives/Public/www-svg/2007Feb/0018.html.
I don't think this is something text engines give you access to? And i'm
not sure how this is supposed to apply to a string.

A quick summary of pointer-events for my benefit:
visiblePainted                                    receive events if if
either fill or stroke and visibility=visible
visibleFill, visibleStroke, visible        receive events visibility=visible
fill,stroke,all                                        receive events if
visibility=visible
painted                                                receive events if
fill or stroke not 'none'

'bounding-box' isn't defined specifically for text .

I get the feeling the SVG spec is trying to define the following:
The bounding box is the rectangle that surrounds all glyph cells of a string
Hit testing registers a hit if the user clicks on anywhere within the
union of all glyph cells of a string. Dependent on pointer-events.

But implementations are using the bounding box for hit testing.
And the method for creating the bounding box is a little different on
each - and it's not totally obvious to me what method they are using.
My test file is at: http://codepen.io/anon/pen/LlAIc (Requires an MS
font called Gabriola that has lots of fancy flourishes).

> 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".
Is it really going to slow things down noticeably if we use the actual
geometry?


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 Friday, 14 March 2014 05:22:05 UTC