Re: feImage coordinates question

On Mon, 12 Jul 2010 11:42:45 +0200, Jasper van de Gronde  
<th.v.d.gronde@hccnet.nl> wrote:

> Erik Dahlstrom wrote:
>> ...
>>> Why is it different from the default of
>>>          the filter effects region? (BTW, adding primitiveUnits =
>>>          objectBoundingBox without adding x, y, width, and height
>>>          breaks Batik.)
>>  I'm not exactly sure of the history, but I think it's deliberate,  
>> there are other examples in the spec using the same convention e.g  
>> <mask> and <pattern>.
>
> My interpretation has always been that userSpaceOnUse is usually what  
> you want to work with (after all, that's basically what you normally use  
> as well), but objectBoundingBox is more useful if you want to specify a  
> portion of the bounding box (obviously), which is what is done with the  
> filter effects region.

In my experience 'userSpaceOnUse' filters more or less require you to use  
an authoring tool (or to always use the same viewport), and that makes the  
filter less reusable. 'objectBoundingBox' filters are slightly more  
portable (you can copy-paste the code to other documents and expect it to  
just work) since they depend only on the geometry of the element they're  
applied to (there are cases where it's hard though, e.g overflow from  
feGaussianBlur).

>>  From 15.7.3:
>> [[ If there are no referenced nodes (e.g., for ‘feImage’ or  
>> ‘feTurbulence’), or one or more of the referenced nodes is a standard  
>> input (one of SourceGraphic, SourceAlpha, BackgroundImage,  
>> BackgroundAlpha, FillPaint or StrokePaint), or for ‘feTile’ (which is  
>> special because its principal function is to replicate the referenced  
>> node in X and Y and thereby produce a usually larger result), the  
>> default subregion is 0%,0%,100%,100%, where percentages are relative to  
>> the dimensions of the filter region. ]]
>>  I agree that it could be made more clear, anyway the last part of the  
>> sentence is where it matters. If you don't explicitly specify  
>> x,y,width,height on the filter primitive element (feImage in this  
>> case), then the default (lacuna) filter primitive subregion is the  
>> filter region. You can try yourself what happens if you put the same  
>> values in explicitly (x="0%" y="0%" width="100%" height="100%"), the  
>> rendering is completely different since the percentages are relative to  
>> the viewport not to the filter region.
>
> Just to clarify: I assume percentages used for x,y,width,height of a  
> filter primitive subregion (at least when  
> primitiveUnits="userSpaceOnUse") are ALWAYS relative to the filter  
> region?

No, userSpaceOnUse means the same as anywhere else (percentages are  
relative to the viewport [of the element that had the filter property])  
see  
http://www.w3.org/TR/SVG11/filters.html#FilterElementPrimitiveUnitsAttribute  
:

[[ If primitiveUnits="userSpaceOnUse", any length values within the filter  
definitions represent values in the current user coordinate system in  
place at the time when the ‘filter’ element is referenced (i.e., the user  
coordinate system for the element referencing the ‘filter’ element via a  
‘filter’ property).
If primitiveUnits="objectBoundingBox", then any length values within the  
filter definitions represent fractions or percentages of the bounding box  
on the referencing element (see Object bounding box units). Note that if  
only one number was specified in a <number-optional-number> value this  
number is expanded out before the ‘primitiveUnits’ computation takes place.
If attribute ‘primitiveUnits’ is not specified, then the effect is as if a  
value of userSpaceOnUse were specified. ]]

It would be strange if 'userSpaceOnUse' should not behave the same as if  
the same percentage was specified on the element you applied the filter  
to, right? Remember that the primitiveUnits are used not just for the  
primitive subregion attributes, but to other attributes too, e.g 'dx' on  
the 'feOffset' element.

I've added a test for this and I'd be happy to get feedback on it:

     http://dev.w3.org/SVG/profiles/1.1F2/test/svg/filters-image-03-f.svg.

Cheers
/Erik

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Monday, 12 July 2010 11:36:23 UTC