From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>

Date: Wed, 29 Aug 2012 17:25:41 +0200

To: www-svg@w3.org

Message-Id: <201208291725.41330.Dr.O.Hoffmann@gmx.de>

Date: Wed, 29 Aug 2012 17:25:41 +0200

To: www-svg@w3.org

Message-Id: <201208291725.41330.Dr.O.Hoffmann@gmx.de>

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). OlafReceived on Wednesday, 29 August 2012 15:26:13 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:29:52 UTC
*