Re: [svg2] radialGradient @fr constraints

On Wed, 29 Aug 2012 14:20:28 +0200, Dr. Olaf Hoffmann  
<Dr.O.Hoffmann@gmx.de> wrote:

> 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.

> What could be the intended effect for a negative 'fr'?

Not sure, I don't think we allow circles to have a negative radius  
anywhere else in svg.

> Define, that the absolute value has to be used, if there is no intended
> effect known.
> This is better as to disallow, because if the viewer fixes this, the  
> authors
> cannot fail by accident anymore ;o)

I agree.

> By the way, define what this means (by formula), Figure 8:
> 'a fill equal to the weighted average of the colors in the gradient  
> vector'
> - especially define in detail the weight factor (proportional to the  
> radius
> difference between to colours stops or to the area of between two stops?
> else?)

For interop I agree that it would be nice to have the formula for  
computing the weighted average in the spec.

> 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?


-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Wednesday, 29 August 2012 13:54:31 UTC