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

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

From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
Date: Thu, 14 Jan 2016 21:36:53 +0000
To: Sebastian Zartner <sebastianzartner@gmail.com>
CC: www-svg <www-svg@w3.org>
Message-ID: <11F57DD3-9C75-428C-AD46-01FA0D8DE31D@cisra.canon.com.au>
Hi Sebastian,

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

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

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.

Hope that helps.
Nikos.


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, 14 January 2016 21:37:34 UTC

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