Bug 15537

Summary: The image renders with apparent transparency
Product: WebKit Reporter: Paul Dunning <pauld>
Component: SVGAssignee: 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 Flags
Screen shot of what I am seeing in Webkit
none
This is what I see with the Adobe Plugin
none
The problematic file none

Description Paul Dunning 2007-10-17 03:57:38 PDT
1 - Go to http://www.worldofpaul.com/r.svg
2 >> Note that the 3D image appears to show the background through the letter. What appears to be happening is the individual shapes which make up the curved edges aren’t connecting, so you get a false transparency effect. You can see into and through the letter, as well as through to the background. The image should be solid.

By contrast, Adobe's  own SVG plugin (which I am using with Safari 2) renders the graphic as expected.

The image was created in Illustrator CS3 using the 3D tool and saved as an SVG.
Comment 1 Paul Dunning 2007-10-17 04:00:46 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.
Comment 2 Paul Dunning 2007-10-17 04:02:32 PDT
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.
Comment 3 Paul Dunning 2007-10-17 04:18:16 PDT
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.
Comment 4 Mark Rowe (bdash) 2007-10-17 04:29:21 PDT
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.
Comment 5 Paul Dunning 2007-10-17 04:40:14 PDT
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.
> 

Comment 6 Mark Rowe (bdash) 2007-10-17 04:45:42 PDT
(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.
Comment 7 Mark Rowe (bdash) 2007-10-17 04:48:59 PDT
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.
Comment 8 Mark Rowe (bdash) 2007-10-17 05:01:02 PDT
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.
Comment 9 Eric Seidel (no email) 2007-10-17 11:06:04 PDT
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.
Comment 10 Eric Seidel (no email) 2007-10-17 11:21:41 PDT
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.)
Comment 11 Eric Seidel (no email) 2008-01-19 02:19:14 PST
Closing as invalid.  ASVs behavior seems wrong here.  Please reopen if you disagree.