- From: Erik Dahlstrom <ed@opera.com>
- Date: Mon, 12 Jul 2010 11:24:41 +0200
- To: www-svg@w3.org
On Sat, 10 Jul 2010 17:46:43 +0200, Tavmjong Bah <tavmjong@free.fr> wrote: > > Hi, > > I've been trying to understand the feImage spec as Inkscape's rendering > of a PNG via feImage is quite different from others. So I've trace > through the spec all the relevant parts. Here is what I find: > > > Filter effects region: > > filterUnits = userSpaceOnUse or objectBoundingBox (default) > > filter "hard clipped" to x, y, width height > (default: -10%, -10%, 120%, 120%) > > primitiveUnits = userSpaceOnUse (default) or objectBoundingBox > > > Filter effects subregion (filter primitive attribute) > > filter primitive "hard clipped" to x, y, width height > (default: 0%, 0%, 100%, 100%) > > * First weirdness: the default is specified in percent, > i.e. objectBoundingBox, but primitiveUnits default is > userSpaceOnUse. Shouldn't the primitiveUnits default also be > objectBoundingBox? That would break a lot of content. The difference between those two is quite dramatic. > 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>. 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. > feImage primitive > > Coordinate system depends on "primitiveUnits" > > Image is to be rendered according to the "image" element which > specifies that an image is rendered by default so that it > is centered in the specified viewport with at least two > opposite sides touching the viewport sides. > > * Second weirdness: The coordinate system "depends on the value > of attribute 'primitiveUnits'" which defaults to bounding box > of the referenced object. No, it defaults to 'userSpaceOnUse': [[ 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). ]] > As I read the spec it says that an > image drawn via the feImage primitive should be drawn by > default so that two opposite edges touch the bounding box > (i.e. xMidYMid). Well, yes 'preserveAspectRatio' defaults to 'xMidYMid'. However, the feImage edges would touch the referenced element's boundingbox only if primitiveUnits="objectBoundingBox" was specified. > This is what Inkscape does. However, Batik > and other browsers draw the image so that two opposite edges > touch the edges of the filter effects region. Yes, that is the default when nothing else was specified. Maybe that's the only thing missing in Inkscape? It would be useful to test each of the x,y,width,height being unspecified and also comparing to when they are specified and are percentages. 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 09:25:18 UTC