[Bug 11083] New: filters-offset-02-b.svg

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11083

           Summary: filters-offset-02-b.svg
           Product: SVG
           Version: SVG 1.1 Full
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Filter Effects
        AssignedTo: schepers@w3.org
        ReportedBy: krit@webkit.org
         QAContact: www-svg@w3.org


I think filters-offset-02-b.svg of the 1.1se test suite is wrong on the first
rect [1]. To the relevant part:

<defs>
    <filter id="feoffset1" primitiveUnits="objectBoundingBox" x="0%" y="0%"
width="200%" height="200%">
        <feFlood width="100%" height="100%" flood-color="lime"/>
        <feOffset dx="0.1" dy="0.2"/>
    </filter>
</defs>
<rect x="60" y="70" width="100" height="100" fill="red"/>
<rect x="50" y="50" width="100" height="100" fill="red"
filter="url(#feoffset1)"/>

The first rect is the reference rect. According to the test, the result of the
filter on the second rect should match the first rect. In my eyes this is wrong
because of the following reasons:

The filter region in absolute coordinates is (50,50,200,200) 0% 'difference' to
the target rects position and 200% of its width and height. /*numbers in braces
mean: (x,y,with,height)*/

The filter primitive subregion of feFlood is (50,50,100,100), because no 'x' or
'y' was specified, so we take the filter regions location. The width or height
is 100, because 'width' and 'height' were specified and the 'primitiveUnits'
are set to 'objectBoundingBox'. So we take the '100%' of the targets width and
height.

The feOffset primitive has no 'x', 'y', 'width' or 'height' specified.
According to the spec we take 0%,0%,100%,100% of the filter region if no
previous effect was defined, or take the union of the subregions of all input
primitives otherwise.
In our case the union is the subregion of feFlood: (50,50,100,100).

This subregion interacts as a 'hard clipping' region. Means the result of the
feOffset effect gets clipped to this region.
The resulting effect would have the region (60,70,100,100), but because of the
subregion, this result gets clipped to (60,70,90,80). And this is exactly what
Firefox and WebKit are doing.

I guess Opera does not clip the result to the subregion at the end, but did not
investigate. The current expected result is wrong, we should see a red area in
the bounds of the first black stroked rect.

Look at the 2nd and 3rd paragraph on
http://www.w3.org/TR/SVG/filters.html#FilterPrimitiveSubRegion
 for the relevant part of the spec.

[1]
http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObject/filters-offset-02-b.html

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 18 October 2010 13:26:00 UTC