Re: [svg2] radialGradient @fr constraints

Erik Dahlstrom:

>Olaf: 
>> Looks like the canvas approach is incompatible with the SVG approach.
>> To avoid backwards incompatibilities one could use 'fr' to trigger the
>> behaviour for the problematic cases:
>>
>> If 'fr' is not set or 0, use the old SVG approach to automatically  
>> correct
>> 'fx' and 'fy' to be not outside the circle (this has the advantage for
>> authors, that they do not have to calculate this manually - and the  
>> result
>> is stable, does not depend on differences of the calculation of the  
>> author
>> and the viewer, because the author is not required to calculate).
>>
>> If 'fr' is not set to 0, do not correct 'fx' and 'fy', following the new
>> 'canvas' approach.
>> Advantage - does not break current content (I have for example such
>> files - and it was annoying to see in the past, that some viewers did not
>> manage to do the correction, resulting in a nonsense display).
>> Minor disadvantage - the 'canvas' approach cannot be used with exactly
>> fr="0", but because this is usually not noticable different from  
>> something
>> like fr="1e-20" this should be no restriction for authors wanting to get  
>> such
>> an effect.

>If 0 is handled like this it can lead to unexpected effects when animating  
>the radius, but sure, it's avoidable by staying clear of fr=0. I think  
>this is the most reasonable option if we want to avoid breaking old  
>content.

If there is no negative value meanigful, there is no big risk for animation,
because '0' would be the limes. If the author does not set it as a value, it
will not appear.
Having not the correction behaviour, but needing it results in much more
trouble for authors - this will result in a lot of number crunching to get
the right values and timing for animation, one has to check and to calculate
the correction for the complete intended animation function, not just for a
few values ;o)

But there is yet another way to trigger:

Lacuna/default value: fr="none"
If fr has a numerical value, do not correct and do the 'canvas' approach.
If fr is none (or invalid), use the correction from SVG.

If an author wants the old approach with correction, he will not care
about fr - and indeed it looks simple to simulate the effect of fr with 
a clever choice of stops anyway.
If an author wants the new approach without corrections, even in animation
he will only use numerical values and no problem will occur.
If one needs to switch the behaviour, on still can set or discrete animate
to 'none'.


...

>> And define an accuracy level for the question, whether the focal point
>> is on the circle or inside or outside, else the rules for the weight  
>> factor
>> remains for very exotic cases like fx="0" or fy="0", because for other
>> cases typically due numerical rounding issues the questionable
>> corrected point will not be exactly on the circle.
>> Maybe even for fx="0" or fy="0" there will be rounding issues, if the
>> object or the gradient is somehow transformed.
>
>Hmm... what should the accuracy level be in that case?

The rules could be:
a) If correction applies (obviously) the point is on the circle.
b) If minimal distance between circle and point devided by
the radius of the circle is below 1e-8* assume the point is on
the circle, respectively (tiny rule) if the difference is below 0.0001
local units, put the point on the circle.

With rule a) authors can get the averaging simply by setting the
point slightly outside.

If 'chaotic' behaviour does never occur, if the point is close to
the circle, but inside, there is no need of course for b) at all,
but I did not test it. 
Does the canvas approach have a similar problem, if the point
is close to/on the circle (because canvas needs scripting, I never cared
about it and I have never seen, that anybody uses it)?
However if this matters or to find out, whether it matters:

* 1e-8 too small/ not small enough?
Better to provide a limit in pixels of the viewport?
Maybe one needs some test files (doing statistics with gradients in
local units, boundingBox units, huge differences in the size of the 
circle etc)  to decide, at which typical distances there is a tendency 
for 'chaotic' behaviour ...
Maybe one gets something simple like chaotic behaviour 
for distances clearly below one viewport pixel - then it is
obvious, what is intended to be avoided by this weighted 
average rule and the limit is found...
On the other hand, maybe some authors like the interesting,
'chaotic' structures? This might mean, that one needs an 
option for authors to set the limit manually, maybe with
an additional value auto (if the values resulting from the
statistics is not trivial to note for authors).


By the way, more interesting than 'fr' would be an option
to be able to set spreadMethod for the begin and the end of
a gradient differently ...
(possible to simulate with SVG 1.1 as well, of course).


Olaf

Received on Wednesday, 29 August 2012 15:26:13 UTC