Bug 15537 – The image renders with apparent transparency

• Status: RESOLVED
• Resolution: INVALID
• Component: SVG

[Paul Dunning]

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.

[Paul Dunning]

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.

[Paul Dunning]

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.

[Paul Dunning]

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.

[Mark Rowe (bdash)]

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.

[Paul Dunning]

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.
> 

[Mark Rowe (bdash)]

(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.

[Mark Rowe (bdash)]

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.

[Mark Rowe (bdash)]

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.

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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.)

[Eric Seidel (no email)]

Closing as invalid.  ASVs behavior seems wrong here.  Please reopen if you disagree.