I would like to discuss a potentially very serious compatibility issue with our filters implementation. The question is, If an object has a transform, do the filters apply to it _before_ or _after_ transfomation? To illustrate this, do the following:
- draw a circle
- blur it
- squeeze it vertically (note the blur is also squeezed, i.e. x-blur is greater than y-blur)
- rotate the object
At this stage in Inkscape, the blur remains horizontal, so it is no longer parallel to the object itself, so the appearance of the object changes very visibly after the rotation. If however you now save your file and view it in Batik, you will see that it rotates the blur too, so the object looks exactly the same as before rotation.
Note that Inkscape differs from Batik only after you add rotation. For non-uniform scaling, Inkscape emulates Batik's behavior by scaling the x and y deviations of the blur filter when applied to a scaled object. However, such emulation is not possible for rotation or shear, hence the discrepancy.
Now, I could not find a definitive indication in SVG 1.1 standard as to which of the two behaviors is correct. (I may have missed it, of course.) Some arguments can be found in favor of both behaviors:
Batik:
- It is more visually consistent because rotation/shear does not alter the appearance of a filtered object in a confusing way
- So far, we always considered Batik an authoritative renderer (though it may be in error too, of course)
Inkscape:
- The idea of transforming an already filtered object (i.e., in essence, a bitmap!) goes absolutely against our architecture, in which rasterization and filtering are always the last step after all things that can be done in vector (such as transforms) are done. If we try to fix this to match Batik, we will need to implement a separate bitmap transformer (!) which will have to be run for filtered objects _only_ (otherwise we'll end up with pixelated renditions of any scaled-up object). This will be a total mess from the programmer's viewpoint if you ask me.
- Our behavior preserves the same appearance of a path regardless of whether its transform is embedded or given in a transform= attribute (but this is currently only true for rotations, not for non-uniform scales). This is a principle which we're kinda trying to uphold, although it's not always possible.
I _think_ that even if our behavior is an error, it's not a reason enough to stop 0.45, because this only affects squeezed _and_ rotated objects. However it's still very serious because it's a visible rendering discrepancy. So I would like to discuss this issue and the approach we should eventually pursue.