WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
113439
DOM floating point support for text size (especially in SVG)
https://bugs.webkit.org/show_bug.cgi?id=113439
Summary
DOM floating point support for text size (especially in SVG)
Alan Oursland
Reported
2013-03-27 13:58:11 PDT
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.
Attachments
Show use of text-rendering hint
(2.41 KB, text/html)
2013-03-29 22:35 PDT
,
Philip Rogers
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Philip Rogers
Comment 1
2013-03-29 22:34:45 PDT
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
Comment 2
2013-03-29 22:35:09 PDT
Created
attachment 195841
[details]
Show use of text-rendering hint
Philip Rogers
Comment 3
2013-04-02 12:00:00 PDT
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
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug