On 12/28/06, Daniel Pope <mauve@...1559...> wrote:
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:
- Block on this, delaying release until it's fixed (how much work is a
fix?)
Hard to say until one tries. Of course 3 would be the best option if someone would step forward and make a commitment to fix this within some reasonable time frame (say a couple weeks). Unfortunately this can't be me because I'm rather swamped with other work and it's not my domain of expertise anyway. And without such a commitment from someone, I don't think we can really delay 0.45 any longer.
- 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.
The 4 is kinda implied; of course we will add a prominent note to Release Notes. Giving any special moniker to the release is not necessary, because we are officially under 1.0 anyway.
- 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.
That may be possible but it should not affect our decision of what to do now.
- 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.
No, that is not an option. Blur is a big part of the reason for releasing 0.45 at all. Lots of people look forward to it. Most users will never have problems from this incompatibility, especially if we implement 2 (which should be relatively easy). However personally I'm against 2, because it will look too much like a bug for those who run into it. I think the change in rendering after we fix rendering will in most cases be slight and therefore less of a problem than 2.