MenTaLguY wrote:
Well, it looks like Inkscape's behavior is non-compliant at the moment, but only under certain combinations of transformations (generally, rotation + non-uniform scaling). bulia and I have been discussing this, and since reworking filters will take a while, we think we have two options for this release:
leave the behavior as it is
disable filter rendering when the output would be non-compliant
Which one should we go with? Other suggestions?
They both sound pretty dreadful and each could be problematic to a different subset of users.
There are a few other options I can suggest:
3. Block on this, delaying release until it's fixed (how much work is a fix?)
4. Keep users informed. Brand release specifically as alpha to suggest that blur filters applied with this version could still change in future versions and suggest that 0.44 may be more 'stable' with respect to the SVG spec. This is not much different to 3, in fact, as the webpage already differentiates between development versions and releases.
5. Leave behavior as is but add special code in future to correct SVG files in which inkscape:version implies that the filter was originally wrong. Would allow for backward compatibility in 0.46 on but doesn't fix compliance for 0.45. Would also specifically have to deal with flagged objects in future.
6. Disable blur controls unless an option in Inkscape preferences is checked. The options page could explain the compatibility/conformance issue and let users take responsibility for enabling it.
I prefer 3, 4 or (to a lesser extent 6) to 1 and I don't care much for 5 or 2. 2 would be more acceptable if there was some feedback for users every time a filter is prevented from rendering.
Dan