Summary: | REGRESSION(Safari3-TOT): SVG renders improperly | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Mike <1337mail> | ||||
Component: | SVG | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | eric, oliver, rwlbuis, zimmermann | ||||
Priority: | P2 | Keywords: | NeedsReduction, Regression | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Mac | ||||||
OS: | OS X 10.4 | ||||||
URL: | http://upload.wikimedia.org/wikipedia/commons/1/1c/NYCS_map_V.svg | ||||||
Attachments: |
|
Description
Mike
2008-01-20 23:04:42 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. 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. |