RESOLVED FIXED Bug 36731
SVG Glyph transformations wrong on use of SVGFont
https://bugs.webkit.org/show_bug.cgi?id=36731
Summary SVG Glyph transformations wrong on use of SVGFont
Dirk Schulze
Reported 2010-03-28 13:15:15 PDT
The translation of SVG Glyphs can be wrong on using SVGFont. However the rotation of Glyphs is correct. Examples: http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/text-path-02-b.html http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/text-text-07-t.html http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/text-text-09-t.html It's possible, that the not working square glyphs tests on the Test-suite have the same reason for the brokness.
Attachments
SVGFont text and serif-font text should lie one upon the other. (946 bytes, image/svg+xml)
2010-03-28 14:13 PDT, Dirk Schulze
no flags
Patch (55.80 KB, patch)
2010-03-29 11:10 PDT, Dirk Schulze
no flags
Patch (80.58 KB, patch)
2010-03-29 13:35 PDT, Dirk Schulze
no flags
Dirk Schulze
Comment 1 2010-03-28 14:07:30 PDT
After checking SVGInlineTextBox::calculateGlyphBoundaries it turns out, that only the x-Position is wrong, caused by a wrong x-Position of SVGChar.x. Another very strange issue: The values depend on the chars that are used and how they are combined. Combining the same characters results in the expected output. Some other combinations cause wrong positioning of the chars. I try to upload a short test case to demonstrate this.
Dirk Schulze
Comment 2 2010-03-28 14:13:49 PDT
Created attachment 51868 [details] SVGFont text and serif-font text should lie one upon the other. Note, that only the x-position is wrong, and only on the left example.
Dirk Schulze
Comment 3 2010-03-28 14:21:15 PDT
*hmpf* Looks like I found the problem. The SVGFont in this test is using hkern. We don't support hkern or vkern. That causes the trouble.
Dirk Schulze
Comment 4 2010-03-28 14:45:48 PDT
Looks like I was wrong again (someone should update the SVG status page). We support kerning and deleting the kerning values causes _my_ expected rendering. Compared with Opera, it looks like Opera don't respect the kerning. Shouldn't we use kerning on glyph-transformation? Is our rendering correct, but the rendering of Opera is wrong? Do we have a bug in kerning?
Dirk Schulze
Comment 5 2010-03-29 04:20:57 PDT
The value of the kerning should be relative to the userSpace of the Char. WebKit takes the userSpace of the viewport.
Dirk Schulze
Comment 6 2010-03-29 11:10:49 PDT
Darin Adler
Comment 7 2010-03-29 12:31:59 PDT
Comment on attachment 51934 [details] Patch > + kerning = static_cast<float>(kerningPair.kerning); I think we have a special cast just for the "double to float" conversion. With the word "narrow" in its name. I don't have a source tree handy.
Dirk Schulze
Comment 8 2010-03-29 13:01:32 PDT
(In reply to comment #7) > (From update of attachment 51934 [details]) > > + kerning = static_cast<float>(kerningPair.kerning); > > I think we have a special cast just for the "double to float" conversion. With > the word "narrow" in its name. I don't have a source tree handy. Your're right, narrowPrecisionToFloat. Forgot this.
Dirk Schulze
Comment 9 2010-03-29 13:35:29 PDT
Nikolas Zimmermann
Comment 10 2010-03-30 01:54:05 PDT
Comment on attachment 51961 [details] Patch Good catch, r=me!
Dirk Schulze
Comment 11 2010-03-30 04:31:00 PDT
Comment on attachment 51961 [details] Patch Clearing flags on attachment: 51961 Committed r56776: <http://trac.webkit.org/changeset/56776>
Dirk Schulze
Comment 12 2010-03-30 04:31:09 PDT
All reviewed patches have been landed. Closing bug.
Eric Seidel (no email)
Comment 13 2010-03-31 17:17:51 PDT
svg/custom/glyph-transformation-with-hkern.svg has been failing on the Gtk 32-bit Debug builder since this change.
Dirk Schulze
Comment 14 2010-04-01 22:40:20 PDT
Note You need to log in before you can comment on or make changes to this bug.