1078743 - svg getBBox() on text elements returns wrong rectangle data

Status: VERIFIED FIXED

(Core :: SVG, defect)

Description

[thomas.smailus]

Attachment: getBBox test.svg

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20140825060242

Steps to reproduce:

Load attached SVG diagram, which calls getBBox() on a text element in the diagram and reports back the result.  The result does not make sense for the text element's precisely known location and dimension specification.


Actual results:

A text string is positioned at 110,110 textLength=30 font-size=10
calling getBBox() returns 
(x,y)=(0,-14.839999198913574); 
w:131.4351806640625; 
h:129.29200744628906
with some variation in the decimal places depending on the Firefox window size.


Expected results:

Should have retuned x,y = 110,110 and width=30  and height around 10 (driven by font-size)

Comment 1

[Robert Longson [:longsonr]]

Height is affected by ascenders and descenders. y is affected by leading.

Comment 2

[thomas.smailus]

Yes, that is true, so I'd expect height to be somewhere around 10 but not 129.2xx.
If the position is 110,110, the location for y should be around 110, not -14.83

And x should be around 110, not 0

Comment 3

[thomas.smailus]

Marked as invalid - I don't see how - please explain... setting status to Unconfirmed.

Comment 4

[Robert Longson [:longsonr]]

x is around 110 and y is around 97 on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0

I'll check Windows.

Comment 5

[Robert Longson [:longsonr]]

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0

basically the same i.e. 110,95.4

Could be something fixed in 32 or maybe something add on is breaking things for you

Comment 6

[thomas.smailus]

This isn't fixed on 31.1.0 ESR - thats where it needs to be fixed.  Is the ESR release an 'other' branch or how does one indicate this?

Comment 7

[Robert Longson [:longsonr]]

Are you saying that 32 works but 31 esr does not? If so and you find what fixed it via http://mozilla.github.io/mozregression/ then it might be possible for that fix to be ported to ESR 31 depending on how big the patch is and what it depends on.

Comment 8

[thomas.smailus]

I know the bug exists in Firefox ESR 31.1.0  (and it used to not exist in the ESR 24.x version we were using before - so our ESR regressed in functionality by going to ESR 31.1.0.

You indicated that it is fixed in main line 32.0.

Testing myself in Firefox 33.0 it seems to be fixed, or at least better.
The sample test case text that starts at 110,110 and has textLength=30, font=10 returns a bbox of x,y=108.75, 97.20 width=33.75, h=15.36

So the bounding box, while the bounding box is still more expansive than I'd expect given the text is specified as starting at 110,110 and (so why the BBox comes back starting at < 110 is a point of discussion, or why the height is 15.36 if the font size is 10 )  at least the bounding box is in a usable area (bbox.x is no longer negative and off the screen)

This issue is related to how BBox is compute when the text has some whitespace in it, specifically leading newline and tab characters.  The problem manifests because the SVG test case has text defined as follows:

	<text id="inText" x="110" y="110" textLength="30" lengthAdjust="spacingAndGlyphs" text-anchor="start">
		<tspan  font-family="ocrb ata" fill="black" id="SS61" font-size="10"  >TERM-S</tspan>
	</text>

So the text starts with a newline and then two tabs and the the tspan, followed by another newline and tab.  I believe the computation of the bounding box when the text starts and ends in whitespace is the underlying issue.

I've attached an enhanced test diagram, that takes that initial test and adds a a rectangle (green) that is resized to the position and dimensions reported by getBBox().  The grey rectangle depicts the zone specified to cover the area from the text location with a width of the textLength, and a height of the font-size.  The orange/peach box depicts the region that is the SVG viewBox, for orientation purposes.

Comment 9

[thomas.smailus]

Attachment: Test getBBox on a text-tspan combination with leading and trailing whitespace

Comment 10

[Robert Longson [:longsonr]]

The bounding box allows for ascenders i.e. the decender of a y and an accent on a capital so it's bigger than the actual text you use in the case you have.

What's left sounds like bug 1019555 then. I'm not sure we'd port that to ESR but you could try asking in that bug.