Bug 113439 – DOM floating point support for text size (especially in SVG)

• Component: SVG
• Status: RESOLVED INVALID

[Alan Oursland]

Summary

I am trying to force text in SVG to have an exact position and size across browsers and systems. The <text> tag produces very inconsistent results (which I would like to see fixed, but seems like a more difficult problem). As a work around, I am attempting to scale the text using a desired width and the width of the text as reported by the DOM. 



I have used the following DOM methods in an attempt to get the text width:



- SVGTextContentElement.getComputedTextLength()

  http://www.w3.org/TR/SVG/text.html#InterfaceSVGTextContentElement



- SVGLocatable.getBBox().width

  http://www.w3.org/TR/SVG/types.html#InterfaceSVGLocatable

  http://www.w3.org/TR/SVG/types.html#InterfaceSVGRect



- Element.getBoundingClientRect().width

  http://www.w3.org/TR/cssom-view/#the-getclientrects-and-getboundingclientrect-methods

  http://www.w3.org/TR/cssom-view/#clientrect



Each of these DOM members are defined to return floating point values by the w3c. Chome, Firefox, and IE each return floating point values for some of these DOM members. Opera and Safari both return rounded-off integers for all of them. The result is the scaling factor I generate to size the text perfectly is off by a small amount and the text jitters as the zoom level is changed.



As a workaround, I can use a very, very large font or viewport to reduce the impact of the loss of precision due to round-off. However, I'm not crazy about that solution.



getComputedTextLength is the most important one to fix for me since it is the only one of the three that Chrome returns floating point for.



I've attached an HTML sample file that can be used for testing.



Steps to Reproduce:



1. Open the attached file.

2. In the text input labeled "Font Size", enter different font sizes and press enter.



Expected Results:



The text should always be the same width as the red box.



Actual Results:



The text size changes to be slightly larger and smaller than the red box.



Regression: 

No



Notes:

Try setting the font size to something large like "2200". The text is nearly the same size as the box, but goes outside of it by a small amount. Changing the font size to "2300" changes the size of the text a little bit. It is an improvement over the change from "22" to "23", but still isn't perfect.

[Philip Rogers]

The values returned from getComptuedTextLength() are not rounded but represent the actual widths used. WebKit is snapping glyphs to integer boundaries, not the returned values. I put together a small test to show this in textlength.html. Notice that the green boxes are drawn correctly at the glyph boundaries.

It looks like your issue is that a glyph of width N does not have width N*S after scaling by S. In WebKit this is the intended behavior but we've implemented the "text-rendering='geometricPrecision'" property for exactly your usecase. (http://www.w3.org/TR/SVG/single-page.html#painting-TextRenderingProperty)

In the attached textlength.html file I show a little example of how to exactly size a textrun inside a box of any width. Does this solve your usecase?

[Philip Rogers]

Created attachment 195841 [details]
Show use of text-rendering hint

[Philip Rogers]

From an email with Alan it sounds like this is now working for him.

If that isn't the case, please comment and we can reopen!

Marking as invalid