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

Re: Margins for filters?

From: Dirk Schulze <vbs85@gmx.de>
Date: Sun, 18 Apr 2010 15:06:17 +0200
To: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>
Cc: robert@ocallahan.org, Erik Dahlstrom <ed@opera.com>, www-svg@w3.org
Message-ID: <1271595977.23486.90.camel@dirk-laptop>
I don't want to distract from filters. But another point, that I don't
understand in this discussion about margin, is masking. Doesn't masking
have the same problem?

<svg xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<defs>
<mask id="mask">
  <circle cx="50" cy="50" r="50" fill="white"/>
</mask>
</defs>
<line x1="0" y1="50" x2="100" y2="50" stroke-width="100" stroke="green"
mask="url(#mask)"/>
<rect x="0" y="0" width="100" height="100" fill="green"
mask="url(#mask)" transform="translate(100,0)"/>
</svg>

We only see one green circle, because the boundingBox of the line has a
height of zero. So why fix this "issue" on filters with margin, but not
on masking?

Dirk



Am Sonntag, den 18.04.2010, 14:25 +0200 schrieb Jasper van de Gronde:
> Dirk Schulze wrote:
> >> More fundamentally, the filter effects region is not MEANT to be a 
> >> general clipping facility, and is frankly a pretty poor substitute.
> > Rob wrote a mail about the unclear description of clipping and filter
> > effects in the Specs some time ago. On WebKit we interpret it the same
> > way like for filterRegions. That means we use subRegions as clipping
> > areas. IIRC batik and Opera do the same.
> 
> Emphasis was intended to be on "general (clipping facility)".
> 
> Put differently: as far as I can tell anything that can be done with a 
> filter effects region can also be done a different (often more generally 
> useful) way. Being able to ignore the option reduces complexity of 
> implementations (or keeps it more or less the same) and confusion. It is 
> not uncommon to get bug reports that boil down to some oddity caused by 
> having a filter effects region specified.
> 
> Now, completely removing the option at this point might be troublesome, 
> but we could try working towards that.
> 
> (And indeed, the filterRes property would be another candidate, although 
> I'd have less problems with simply ignoring it.)
Received on Sunday, 18 April 2010 13:06:52 GMT

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