W3C home > Mailing lists > Public > www-svg@w3.org > June 2009

Re: SVG filters feOffset and primitiveUnits

From: Erik Dahlström <ed@opera.com>
Date: Tue, 16 Jun 2009 14:15:50 +0200
To: robert@ocallahan.org, "Dirk Schulze" <vbs85@gmx.de>
Cc: www-svg@w3.org
Message-ID: <op.uvl9oog5gqiacl@gnorps.linkoping.osa>
On Sat, 13 Jun 2009 12:21:31 +0200, Robert O'Callahan <robert@ocallahan.org> wrote:

> On Sat, Jun 13, 2009 at 4:37 AM, Dirk Schulze <vbs85@gmx.de> wrote:
>> I have a question to feOffset in SVG filters
>> ( http://www.w3.org/TR/SVG11/filters.html#feOffset ).
>> dx and dy depend on primitiveUnits. But what does it mean?
>> Does it mean that if primitiveUnits is objectBoundingBox, the number
>> given to dx and dy are interpreted as percentage or still as "pixel"?
> objectBoundingBox units are described here:
> http://www.w3.org/TR/SVG/coords.html#ObjectBoundingBox
>> Then, coordinate (0,0) in the new user coordinate system is mapped to the
>> (minx,miny) corner of the tight bounding box within the user coordinate
>> system of the applicable element and coordinate (1,1) in the new user
>> coordinate system is mapped to the (maxx,maxy) corner of the tight bounding
>> box of the applicable element.
> I notice that Opera agrees with Batik in treating dx/dy numbers as
> user-space units, but I'm still pretty sure we (Firefox) are right according
> to the spec, when we interpret 0.25 the same as 25% of the way across the
> object bounding box.

Interpreting 0.25 as 25% looks to be correct according to the spec yes.

> I agree that this behaviour is very unintuitive and the spec made a
> regrettable decision here. objectBoundingBox units would be a lot more
> useful if percentages referred to the bounding box and numbers were still
> interpreted as user-space units. However, objectBoundingBox units are used a
> lot and I doubt their behaviour can be changed without breaking content.

Changing it would indeed break backwards compatibility, and would also affect the SVG DOM. I'd have to agree that it's confusing that you can use a percentage unit in some places and only fractions in others.

That said, just going through the filter spec I see many attributes that should probably have used another basic type / syntax. Here's a list, heading is the type I'd consider changing to if I was starting out from scratch.

feDistantLight@azimuth = <number>
feDistantLight@elevation = <number>
feSpotLight@limitingConeAngle = <number>

fePointLight@x = <number>
fePointLight@y = <number>
fePointLight@z = <number>
feSpotLight@x = <number>
feSpotLight@y = <number>
feSpotLight@z = <number>
feSpotLight@pointsAtX = <number>
feSpotLight@pointsAtY = <number>
feSpotLight@pointsAtZ = <number>
feDisplacementMap@scale = <number>
feOffset@dx = <number>
feOffset@dy = <number>

feGaussianBlur@stdDeviation = <number-optional-number>
feMorphology@radius = <number-optional-number>
{multiple elements}@kernelUnitLength = <number-optional-number>

Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Tuesday, 16 June 2009 12:14:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:17 UTC