Summary: | The image renders with apparent transparency | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Paul Dunning <pauld> | ||||||||
Component: | SVG | Assignee: | Nobody <webkit-unassigned> | ||||||||
Status: | RESOLVED INVALID | ||||||||||
Severity: | Normal | CC: | eric, mrowe, oliver, zimmermann | ||||||||
Priority: | P2 | Keywords: | NeedsReduction | ||||||||
Version: | 523.x (Safari 3) | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.4 | ||||||||||
URL: | http://www.worldofpaul.com/r.svg | ||||||||||
Attachments: |
|
Description
Paul Dunning
2007-10-17 03:57:38 PDT
Created attachment 16693 [details]
Screen shot of what I am seeing in Webkit
This is what I am seeing in WebKit. Note the apparent transparency in the letter form.
Created attachment 16694 [details]
This is what I see with the Adobe Plugin
This is how Adobe's AVG plug in renders the same file. This is close to the original image in Illustrator, and what I expect to see.
Created attachment 16695 [details]
The problematic file
This is the file that displays the problem. It was created in Illustrator CS3 on a Mac and was saved as an SVG file.
One point of note is that WebKit, Firefox, Opera, and Batik all render this SVG identically. This strongly suggests that Adobe's SVG rendering is the incorrect one. The thing is is that Adobe's plug in is rendering the image correctly. What I see in Illustrator is very, very close to what I see in Adobe's plug-in, and what I expect to see in other SVG viewers. Adobe is clearly getting this right, and the others aren't. (In reply to comment #4) > One point of note is that WebKit, Firefox, Opera, and Batik all render this SVG > identically. This strongly suggests that Adobe's SVG rendering is the > incorrect one. > (In reply to comment #5) > The thing is is that Adobe's plug in is rendering the image correctly. What I > see in Illustrator is very, very close to what I see in Adobe's plug-in, and > what I expect to see in other SVG viewers. Adobe is clearly getting this right, > and the others aren't. Rendering what you *expect* to see and what the SVG file itself describes are two different things. The Adobe SVG viewer may be rendering what you expect to see but be incorrect according to the relevant specifications. Given the consistent behaviour between four different implementations this seems to be the most likely situation, though I've not reduced the SVG file to confirm it. The alternative of course is that four different implementations just happen to have exactly the same bug. While this is not impossible, it does seem unlikely. I've copied a few people that Know Stuff about SVG on this bug. They should be able to tell precisely what is happening here. We'll need to make a smaller test case to compare between ASV and more recent SVG implementations. I should note that Batik (often considered the standard for SVG implementations) renders this identically to Firefox, Safari and Opera. We still need to reduce this to be sure, but I expect this is just an ASV bug. It might be interesting to remove all the enable-background attributes and see if ASV still renders this differently. enable-background only should have any effect on how filters render, not on how the normal content renders. It's possible that enable-background has unintended side-effects for normal rendering in ASV, not sure. (BTW, bug 6022 covers our lack of source="Background" and thus lack of enable-background support, but as I said above, that's completely unrelated to this bug, as enable-background should *not* affect rendering.) Closing as invalid. ASVs behavior seems wrong here. Please reopen if you disagree. |