RESOLVED FIXED 16953
REGRESSION(Safari3-TOT): SVG renders improperly 
https://bugs.webkit.org/show_bug.cgi?id=16953
Summary REGRESSION(Safari3-TOT): SVG renders improperly
Mike
Reported 2008-01-20 23:04:42 PST
On wikipedia, a subway map does not display properly. The improperly rendered SVG is located at http://upload.wikimedia.org/wikipedia/commons/1/1c/NYCS_map_V.svg and the reference PNG rendering is located at http://upload.wikimedia.org/wikipedia/commons/thumb/1/1c/NYCS_map_V.svg/490px-NYCS_map_V.svg.png. I do not know if this is the fault of an improper SVG file or not, but I figured I'd let you guys know so you could determine. Interestingly, the SVG does not render well(i.e. the same as WebKit) on Firefox 3.0b2 on Mac OSX, but DOES render properly on Firefox 2.0.0.11 on Windows.
Attachments
reduction of "failing" SVG (1.24 KB, image/svg+xml)
2009-05-06 18:00 PDT, Eric Seidel (no email) 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Mark Rowe (bdash)
Comment 1 2008-01-21 00:11:50 PST
Safari 3 appears to render this "properly" too, while the nightly build gets it wrong. The fact that both the WebKit nightly and Firefox 3 beta render this improperly in the same fashion suggests there may have been a bug fixed in both WebKit and Firefox since the previous versions.
Oliver Hunt
Comment 2 2008-01-21 00:27:39 PST
Looks to be a font positioning issue
Eric Seidel (no email)
Comment 3 2009-05-06 18:00:10 PDT
Created attachment 30077 [details] reduction of "failing" SVG The trick here is that this SVG uses <tspan> with an x="" offset list. We used to not support x="" offsets lists, and so all chars were just laid out normally. I haven't looked closely enough yet, but I expect that the offset list is just wrong (or not what the author intended), and we're correctly following it. It's also possible that we're not transforming the x values correctly and that there is a real bug here. Again, I just haven't stared at it enough yet.
Nikolas Zimmermann
Comment 4 2009-05-06 18:30:30 PDT
Oh, never noticed this bug. I suspect the SVGCharacterLayoutInfo is properly, because it's calculated right from the DOM values. I guess the painting is faulty. It has to properly detect chunk start/end offsets. Otherwhise individual x/y positions won't be respected properly. Needs further investigation.
Nikolas Zimmermann
Comment 5 2009-05-06 18:37:16 PDT
@Eric: Forgot to mention, that we support x/y/dx/dy offset lists on tspan since almost two years now. The engine (SVGCharacterLayoutInfo) uses x/y/dx/dy stacks just for that. The LayoutTests/svg/custom/text-x-dx-lists.svg tests covers this. There are more tests, but I can't remember atm. So the bug must have a different root. Maybe a combination of wrong chunk start/end detection - while painting transformed tspans.
Eric Seidel (no email)
Comment 6 2009-05-06 19:27:34 PDT
@Nikolas: I'm still not sure this is even a bug. As mentioned above, FF3 matches our behavior here. One of us would need to stare more closely at the text in question to determine if our layout/painting is wrong or not.
Rob Buis
Comment 7 2011-05-15 15:09:27 PDT
I think this problem is fixed now? It seems to me rendered equally on FF, Opera and my webkit build. Cheers, Rob.
Nikolas Zimmermann
Comment 8 2012-02-16 04:28:23 PST
(In reply to comment #7) > I think this problem is fixed now? It seems to me rendered equally on FF, Opera and my webkit build. > Cheers, > > Rob. Confirmed, works just fine in trunk - also the <tspan x=".."> scenarios are pretty well tested in svg/text nowadays.
Note You need to log in before you can comment on or make changes to this bug.