- From: Erik Dahlstrom <ed@opera.com>
- Date: Tue, 06 Jul 2010 14:46:26 +0200
- To: "www-svg@w3.org" <www-svg@w3.org>
- Cc: robert@ocallahan.org
On Wed, 23 Jun 2010 06:41:16 +0200, Robert O'Callahan <robert@ocallahan.org> wrote: > A couple of issues I discovered in the filter spec don't seem to have > been > addressed yet: > http://lists.w3.org/Archives/Public/www-svg/2008May/0013.html I've just had a look at what implementations are doing when it comes to the filter primitive subregions on feGaussianBlur. See the left-hand side in this testcase: http://dev.w3.org/SVG/profiles/1.1F2/ua-tests/gaussianblur-filter-subregion-issue-2334.svg It seems that we have at least four implementations (Opera, Chrome, Batik, Adobe SVG plugin (and I'd assume Illustrator also - untested though)) that conceptually works as "clip the input, apply the filter, clip the output" versus one implementation (Firefox) that conceptually "applies the filter and then clips the output". Inkscape doesn't seem to handle filter primitive subregions (I've tried versions 0.47 and dev-0.48). It can be argued that either way is better or worse (I think that both ways have valid use-cases). Still I'd suggest going with the legacy behaviour (input+output clipping) on this one, and adding a way for SVG Filters 1.2 to say whether input or output clipping is the desired behaviour, e.g by introducing a new filter primitive element feClip. Thoughts? Would the above resolution be acceptable to you? /Erik -- Erik Dahlstrom, Core Technology Developer, Opera Software Co-Chair, W3C SVG Working Group Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 6 July 2010 12:47:03 UTC