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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sebastian Zartner-3
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.)
Shouldn't getBBox() be deprecated in favor of Element.getBoundingClientRect()[4]?

Best regards,

Sebastian
Reply | Threaded
Open this post in threaded view
|

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

Nikos Andronikos
Hi Sebastian,

On 14 Jan 2016, at 12:31 AM, Sebastian Zartner <[hidden email]> 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:

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.
Reply | Threaded
Open this post in threaded view
|

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

Kari Pihkala
2016-01-14 23:36 GMT+02:00 Nikos Andronikos
<[hidden email]>:
> 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.

The bounding box calculation of text elements uses the terms "glyph
cell" and "full glyph cell". I assume textPath and tspan also uses
them.

Can you add clear definitions for "glyph cell" and "full glyph cell"
to the spec? Thay haven’t been defined anywhere and there has been
some confusion what they mean [1][2].

Thanks,
Kari

[1] https://lists.w3.org/Archives/Public/www-svg/2007Feb/0017.html
[2] https://lists.w3.org/Archives/Public/www-svg/2014Mar/0030.html

Reply | Threaded
Open this post in threaded view
|

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

Sebastian Zartner-3
In reply to this post by Nikos Andronikos
Hi all,

sorry for the late reply!

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

On 14 Jan 2016, at 12:31 AM, Sebastian Zartner <[hidden email]> 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:

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
Reply | Threaded
Open this post in threaded view
|

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

Nikos Andronikos
In reply to this post by Kari Pihkala
Hi Kari,

> On 15 Jan 2016, at 6:15 PM, Kari Pihkala <[hidden email]> wrote:
>
> 2016-01-14 23:36 GMT+02:00 Nikos Andronikos
> <[hidden email]>:
>> 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.
>
> The bounding box calculation of text elements uses the terms "glyph
> cell" and "full glyph cell". I assume textPath and tspan also uses
> them.
>
> Can you add clear definitions for "glyph cell" and "full glyph cell"
> to the spec? Thay haven’t been defined anywhere and there has been
> some confusion what they mean [1][2].
>

I agree these terms need a clear definition.
I’ve added the topic to the agenda for the upcoming F2F.

> Thanks,
> Kari
>
> [1] https://lists.w3.org/Archives/Public/www-svg/2007Feb/0017.html
> [2] https://lists.w3.org/Archives/Public/www-svg/2014Mar/0030.html


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.