xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vincent Hardy <vincent.ha...@eng.sun.com>
Subject Re: Question about filter implementation plans
Date Fri, 27 Oct 2000 17:55:43 GMT
Dean,

As we discussed, but for anybody else interested in the question, 
the 'result' attribute is handled by individual filter bridges to
account
for custom implementation that might use an attribute other than 
result in the SVG namespace. This is why 'result' handling is not done
in the SVGFilterElementBridge but in individual bridges instead.
V.

Dean Jackson wrote:
> 
> On Fri, 27 Oct 2000 17:36:02 Vincent Hardy wrote:
> 
> >
> > About the other 2 related features (handling of the various in values
> > and cliping), I think that:
> >
> > a. IN Attribute.
> >
> > Dean is: 1) writing a common utility to extract a Rable source from
> >             the in attribute value.
> 
> Yes, and the "result" attribute.
> 
> >          2) the utility method will take care of the various
> >             predefined sources (such as SourceAlpha, FillPaint, ...)
> 
> I'll see how far I get with that.
> 
> > b. Clip
> >
> > Thierry is writing the bridge side of things (i.e., setting the clip
> > on the various GraphicsNode at creation time, which involves handling
> > the clip property and the clipPath element). GVT already uses the clip
> > (aliased clip, as per spec. IMHO this is bad, I would rather have
> > anti-aliased clip, but this is what the SVG spec recommends).
> 
> I think we need to have an antialiased clip, regardless of what the spec
> says. It just looks ugly (adobe do antialiased).
> 
> Dean
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org

Mime
View raw message