Re: What is SVGGraphicsElement.getBBox() expected to return for textPaths and tspans?

Hi all,

sorry for the late reply!

On 14 January 2016 at 22:36, Nikos Andronikos <
[email protected]> wrote:

> Hi Sebastian,
>
> On 14 Jan 2016, at 12:31 AM, Sebastian Zartner <[email protected]>
> wrote:
>
> Hi all!
>
> I'm Sebastian and it's the first time I'm writing here.
>
> Short summary of why I'm writing:
> I first discussed the behavior of SVGGraphicsElement.getBBox() in a
> Mozilla bug[1]. This lead me to a Chromium bug[2], which itself refers to
> some SVG telcon minutes[3]. The resolution in those minutes is not clear to
> me, though.
>
> So, I have two questions:
> Is getBBox() expected to return the bounding box of the
> surrounding <text> element when called on  a <textPath> or <tspan> element?
> (See the test cases attached to the Mozilla and Chromium bug.)
>
>
>
> To answer your first question, for getBBox() on textPath and tspan, the
> expected result is the bounding box of the glyphs within the respective
> textPath or tspan element. Not the bounding box of the ancestor text
> element as you are seeing in Chrome.
>
> Here is a resolution that you can reference:
> https://www.w3.org/2016/01/14-svg-minutes.html#resolution01
>

Perfect! Thank you for considering my request! (I already assumed Chrome is
wrong, though I wanted to get that confirmed.)


> Keep in mind, this is new in SVG 2 so it will take some time before all
> implementations support this behaviour.
>

Sure, I'll keep an eye on the browser bugs I've mentioned earlier.

I suspect that the Chrome (and WebKit) implementations are old (i.e. not a
> result of the addition of getBBox to the interface for textPath in SVG 2)
> and are a result of the fact that the bounding box used for paint servers
> when the co-ordinate space is objectBoundingBox is the bounding box of the
> ancestor text element - which is the correct behaviour.
>

I see. Thank you for the clarification.

Sebastian