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.
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.
Looks to be a font positioning issue
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.
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.
@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.
@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.
I think this problem is fixed now? It seems to me rendered equally on FF, Opera and my webkit build. Cheers, Rob.
(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.