- 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