- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 12 Jul 2010 13:35:45 +0200
- To: www-svg@w3.org
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