This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11083 - filters-offset-02-b.svg
Summary: filters-offset-02-b.svg
Status: NEW
Alias: None
Product: SVG
Classification: Unclassified
Component: Filter Effects (show other bugs)
Version: SVG 1.1 Full
Hardware: PC All
: P2 normal
Target Milestone: Test Suite
Assignee: Doug Schepers
QA Contact: SVG Public List
URL: http://dev.w3.org/SVG/profiles/1.1F2/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-18 13:25 UTC by Dirk Schulze
Modified: 2010-10-19 07:14 UTC (History)
1 user (show)

See Also:


Attachments

Description Dirk Schulze 2010-10-18 13:25:57 UTC
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