W3C home > Mailing lists > Public > www-svg@w3.org > July 2010

ISSUE-2334 - filter primitive subregion and feGaussianBlur (Was: Re: Announcement: Last Call WD of SVG 1.1 Second Edition)

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
Message-ID: <op.vfe9rozcgeuyw5@localhost>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:45 GMT