User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/2008092816 Iceweasel/3.0.3 (Debian-3.0.3-3) Build Identifier: Gecko 1.9.1b1 (20081007112159) I've noticed that Mozilla clips the edges of SVG shapes that have been applied a blur filter. It appears the renderer creates some kind of a bounding box around shapes, but fails to expand it correctly after the blur is applied, so the edges of the filtered shape can appear clipped. This clipping effect is most pronounced with blur radii between 5 and 15px. Reproducible: Always Actual Results: Here is a small test SVG to show the problem (generated with Inkscape, exported as "plain SVG"): http://valan.net/tmp/mozilla/clipped_edges_of_blurred_shapes.test.svg Here is the Inkscape output, which looks fine: http://valan.net/tmp/mozilla/clipped_edges_of_blurred_shapes.inkscape-output.png Here is the Mozilla (FF 3.1 beta) output where the four edges appear clipped: http://valan.net/tmp/mozilla/clipped_edges_of_blurred_shapes.mozilla-output.png Observed in FF3.0.*, 3.1beta, xulrunner 188.8.131.52
We use GetBBox to get the filter bounding box but this gives the tight bounding box which excludes the stroke width. We need to use something akin to the covered region in appropriate units.
Bug 470542, that I reported, indeed looks like a duplicate of this one at first sight... However, the difference is that mine was a regression (worked fine with Firefox 3.0.x). This bug, on the other hand, is not a regression.
Bug 407542 does not work for me on Firefox 3.0.x. It is cut off at the bottom.
Created attachment 361491 [details] testcase, reduced somewhat I'm not sure what you mean by comment 2, Robert. We use the bbox to do objectBoundingBox calculations, but that's per-spec. I'm not convinced that this is a bug in Mozilla. I think it's just as likely that the filter region defined by the x, y, width and height attributes on the <filter> element is too small, and that's what's causing the clipping. Probably Inkscape tries to set these to produce the smallest filter region possible that will not clip the results, but it could well be getting the calculation wrong. Or perhaps we are. Someone needs to do the math to figure out who's to blame. :-) Of course, arguably the spec is to blame for requiring users to specify the filter region and not allowing the implementation to figure out the optimal size automatically.
You are right. Per http://www.w3.org/TR/SVG/coords.html#ObjectBoundingBox the bounding box does not include stroke-width so this bug is invalid.
Someone want to go out on a limb and mark it so? :-)
Feel free to reopen if you can prove that the bounding box for the filters are sufficient to include both the shapes and the stroke-width of the shapes. Simpler examples i.e. a rect with a large stroke width and a filter would help rather than things composed of paths.
Created attachment 361504 [details] simpler testcase Even simpler testcase shows that if you get the bounds right it doesn't clip.
The filter region stuff in the spec is a real disaster. This isn't the first time that we've followed the spec when others haven't and authors blame us. It's awfully tempting to just stop clipping to the filter region, use the code we already have to figure out the optimal offscreen size, and get the spec changed. It's hard to image that content actually *relies* on this clipping. http://weblogs.mozillazine.org/roc/archives/2008/02/the_best_of_int.html
(In reply to comment #11) > The filter region stuff in the spec is a real disaster. This isn't the first > time that we've followed the spec when others haven't and authors blame us. > It's awfully tempting to just stop clipping to the filter region, use the code > we already have to figure out the optimal offscreen size, and get the spec > changed. It's hard to image that content actually *relies* on this clipping. > http://weblogs.mozillazine.org/roc/archives/2008/02/the_best_of_int.html I agree with you, ROC. I think we've talked about this in the SVG WG before, and I will ask ED of Opera (Filters module editor) if he concurs. http://www.w3.org/Graphics/SVG/WG/track/issues/2223