Bug 36731

Summary: SVG Glyph transformations wrong on use of SVGFont
Product: WebKit Reporter: Dirk Schulze <krit>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: eric, gustavo, zimmermann
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Attachments:
Description Flags
SVGFont text and serif-font text should lie one upon the other.
none
Patch
none
Patch none

Description Dirk Schulze 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.
Comment 1 Dirk Schulze 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.
Comment 2 Dirk Schulze 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.
Comment 3 Dirk Schulze 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.
Comment 4 Dirk Schulze 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?
Comment 5 Dirk Schulze 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.
Comment 6 Dirk Schulze 2010-03-29 11:10:49 PDT
Created attachment 51934 [details]
Patch
Comment 7 Darin Adler 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.
Comment 8 Dirk Schulze 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.
Comment 9 Dirk Schulze 2010-03-29 13:35:29 PDT
Created attachment 51961 [details]
Patch
Comment 10 Nikolas Zimmermann 2010-03-30 01:54:05 PDT
Comment on attachment 51961 [details]
Patch

Good catch, r=me!
Comment 11 Dirk Schulze 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>
Comment 12 Dirk Schulze 2010-03-30 04:31:09 PDT
All reviewed patches have been landed.  Closing bug.
Comment 13 Eric Seidel (no email) 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.
Comment 14 Dirk Schulze 2010-04-01 22:40:20 PDT
Commited DRT update in http://trac.webkit.org/changeset/56971