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

Re: Margins for filters?

From: Dirk Schulze <vbs85@gmx.de>
Date: Mon, 19 Apr 2010 11:24:04 +0200
To: Erik Dahlstrom <ed@opera.com>
Cc: robert@ocallahan.org, Jasper van de Gronde <th.v.d.gronde@hccnet.nl>, www-svg@w3.org
Message-ID: <1271669044.5498.48.camel@dirk-laptop>
Am Montag, den 19.04.2010, 11:08 +0200 schrieb Erik Dahlstrom:
> On Mon, 19 Apr 2010 10:45:32 +0200, Robert O'Callahan  
> <robert@ocallahan.org> wrote:
> 
> > On Mon, Apr 19, 2010 at 8:43 PM, Erik Dahlstrom <ed@opera.com> wrote:
> >
> >> What you are suggesting is to allow the filter primitive subregion to be
> >> larger than the filter region, so calling it 'subregion' sounds wrong  
> >> to me
> >> (editorial, but still, if that change is made I'd like to call it  
> >> 'filter
> >> primitive region' instead).
> >>
> >
> > Sounds reasonable.
> >
> >
> >> Regarding clipping to the subregion, is it your opinion then that this
> >> clipping should take place on the filter input image, on the filter  
> >> output
> >> image, or both? (For e.g feDisplacementMap this can make quite a  
> >> difference)
> >
> >
> > The output.
> 
> So if you wanted to clip the filter input image to the subregion you'd  
> need an additional filter primitive, e.g feOffset, to do it - that may be  
> undesirable.
> 
> Would being able to control the filter primitive region clipping be  
> something worth having? E.g a new attribute regionClip = [ input | output  
> | input-output ].
> 
> Cheers
> /Erik
What would be the clipping area? The subregion / effect region of the
current primitive? Also what happens if you have two inputs?
This problem only appears on the source graphics (SourceGraphic,
SourceAlpha, ...). Should we realy add a new attribute to handle this
case?

Dirk
Received on Monday, 19 April 2010 09:24:43 GMT

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