Re: Clarification of empty filter tag behavior

On Monday, February 9, 2004, 4:05:44 PM, Felix wrote:

FP> The spec does not seem to define the behavior of an empty filter tag,
FP> i.e. a filter tag containing no filter primitives.

Thanks for your comments. The issue you raise was accepted by the SVG
WG on 9 Feb 2004 and assigned an issue number

ISSUE #2004-008: empty filter tag behavior

please quote the number #2004-008: in further correspondence on this
issue. This email reports the results of discussing the issue in the
SVG WG.

For clarity, we consider the case under discussion to be an empty
filter element like this:

<filter id="foo"/>

because it must have an id to be referenced by the filter property,
but is otherwise empty of content and with no other attributes; and we
consider it to have been correctly applied to some graphical object
via the filter property:

filter="url(#foo)"

(The case where filter="none" does not correspond to an empty filter
element and is not discussed further.)

FP> Batik and the Adobe SVG viewer display different behavior, neither
FP> of which is the behavior I would have expected.

FP> Batik treats the empty filter tag as a no-op and renders the
FP> filtered element as if it didn't have a filter property. It
FP> doesn't even clip the element to the filter effects region.

FP> The Adobe Viewer treats the empty filter as resulting in a
FP> transparent canvas, i.e. it doesn't render the filtered
FP> element at all.

FP> What I would have expected, since it seems to be the most
FP> natural extension of the behavior to this special case, is
FP> that the element is rendered unfiltered, but clipped to the
FP> filter effects region.

A filter, if applied to an element, always produces output:

(http://www.w3.org/TR/SVG11/render.html#FilteringPaintRegions):

3.7 Filtering painted regions
SVG allows any painting operation to be filtered. (See Filter Effects.)
In this case the result must be as though the paint operations had been 
applied to an intermediate canvas initialized to transparent black, of a 
size determined by the rules given in Filter Effects then filtered by the 
processes defined in Filter Effects.

In the case where the referenced filter is an empty filter element,
nothing has altered the initial intermediate canvas provided by the
filter region, so this is also the result of the filter (see below).

FP> By default (i.e. if no "in" attributes
FP> are specified), each filter primitive takes an image and
FP> produces a new image, with the original image being the
FP> source graphics and the last image being the overall result
FP> of the filter. (By the way, the first part (that the first
FP> image is the source graphics) is explicitly stated in the
FP> spec, but I couldn't find the second part (that the last
FP> image is the overall result) -- this is of course sort of
FP> obvious, but should be stated explicitly nonetheless.)

The last image is *not* the overall result (its not like Unix command
line filters). There can be several 'results' which must be explicitly
composited onto the transparent black to give the final effect of the
filter. If no compositing happens, the output of any filter children
will have no effect. This is why you do not find it in the spec,
because it is not intended to be there.

FP> It seems natural to assume that if there is no filter
FP> primitive to operate on it, the original image, i.e. the
FP> source graphics, is also the last image,

A filter will only use the source graphic as an input to the filter if
it is explicitly listed as an input. Filters can use other inputs, eg
the source alpha, background image, background alpha, a flood fill, or
nothing.

FP> i.e. the result of the filter. Certainly no fully transparent
FP> "initial image" ever appears in the process

Please see the quoted section 3.7 above.

FP> (as it does
FP> when the elements of a group are composited).
FP> (Item 2 in the description of the example in Section
FP> 15.6 says "that the offscreen for the filter is
FP> initialized to transparent black", but I believe this
FP> is just a misleading way of expressing

No, its the defined initial state of the filter before the child
elements of the filter start manipulating it.

FP> what is better
FP> expressed in the last paragraph of Section 15.1, which
FP> is a statement about filter *primitives*, not about the
FP> filter as a whole. If I am wrong on this and the sentence
FP> in Item 2 is right as it stands, it needs to be put in a
FP> far more prominent place.)

We will certainly consider that, although it seems that section 3.7 is
sufficient. Perhaps a link to 3.7 from 15.3, or an explicit discussion
of the initial filter state could be added,for clarity.

FP> Regarding clipping to the filter effects region:
FP> Section 15.5 is slightly unclear on this -- it says:
FP> "A 'filter' element can define a region on the canvas
FP> to which a given filter effect applies".

Yes. In the case where no explicit filter region is specified (as is
the case of an empty filter element), then:

http://www.w3.org/TR/SVG11/filters.html#FilterEffectsRegion

If x or y is not specified, the effect is as if a value of "-10%" were
specified.

If width or height is not specified, the effect is as if a value of "120%" 
were specified.

If attribute filterUnits is not specified, then the effect is as if a value 
of objectBoundingBox were specified.

So in the case of

<filter id="foo"/>

the transparent black rectangle is 120% of the width and height of the
object bounding box, offset by (-10%,-10%) and equivalent to

<filter id="foo" filterUnits="objectBoundingBox" x="-10%" y="-10%"
width="120%" height="120%"/>


FP> This could mean either that the result of the filter effect is
FP> clipped to the filter effects region, or it could mean that the
FP> filter applies only inside the region, whereas the filtered
FP> element is passed through unchanged elsewhere.

because the fill is applied to 'an intermediate canvas initialized to
transparent black' there is nothing on the canvas so anything outside
the filter region is not drawn. By default, the entire object is
inside the filter region.

This is also the reason for the last sentence in 15.1:

Sometimes filter primitives result in undefined pixels. For example,
filter primitive 'feOffset' can shift an image down and to the right,
leaving undefined pixels at the top and left. In these cases, the
undefined pixels are set to transparent black.

FP> However, Section 3.7 (though it refers twice to Chapter 15 where I
FP> believe the first reference is meant to be to Section 15.5)

I agree that would be clearer

FP> is a bit clearer in implying that the parts of the unfiltered
FP> element lying outside the filter effects region are clipped.

This is correct.

FP> Batik and the Adobe Viewer in general seem to agree on this, but
FP> in the case of an empty filter tag, Batik doesn't clip the
FP> unfiltered element to the filter effects region.

Your analysis is correct; Batik should clip the empty-filtered element
(not the same as an unfiltered element) to the filter effects region.

In conclusion, the SVG WG believes that the effect of applying an an
empty filter element is fully defined in the specification. We will
consider whether the specification can be made clearer in this regard
so that the correct interpretation is more obvious. In addition, we
will add a test for empty filter effects to the test suite.

I hope that you find this response satisfactory.


-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group

Received on Sunday, 15 February 2004 10:34:21 UTC