W3C home > Mailing lists > Public > www-svg@w3.org > January 2016

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

From: Sebastian Zartner <sebastianzartner@gmail.com>
Date: Mon, 18 Jan 2016 09:38:46 +0100
Message-ID: <CAERejNZCSnhCSHC=BVX=EHPBbJ6Rwpu82BX5pM=OqJ2CcDwihA@mail.gmail.com>
To: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
Cc: www-svg <www-svg@w3.org>
Hi all,

sorry for the late reply!

On 14 January 2016 at 22:36, Nikos Andronikos <
Nikos.Andronikos@cisra.canon.com.au> wrote:

> Hi Sebastian,
> On 14 Jan 2016, at 12:31 AM, Sebastian Zartner <sebastianzartner@gmail.com>
> 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.

Received on Monday, 18 January 2016 08:39:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:43 UTC