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

Date: Tue, 4 Sep 2012 12:48:29 +0200

To: www-svg@w3.org

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

Date: Tue, 4 Sep 2012 12:48:29 +0200

To: www-svg@w3.org

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

Jasper van de Gronde: >Glad you like it. And yes, you are indeed correct that if the focus goes >outside the circle, that the gradient then no longer fills the entire >plane (I think it's in there somewhere btw.). Would you consider this a >problem? (I'm not sure what else one would expect.) > >On 03-09-12 21:50, Rik Cabanier wrote: >> Very nice! >> You could also call out that if the focus goes outside the circle, the >> gradient no longer fills the entire path. With all values of spreadMethod the area is completely filled with something: " spreadMethod Indicates what happens if the gradient starts or ends inside the bounds of the target rectangle. " (-> 'target rectangle' seems to be a bug/typo, that needs to be fixed ;o) " pad Use the terminal colors of the gradient to fill the remainder of the target region. reflect Reflect the gradient pattern start-to-end, end-to-start, start-to-end, etc. continuously until the target rectangle is filled. " (-> 'target rectangle' seems to be a bug/typo, that needs to be fixed ;o) " repeat Repeat the gradient pattern start-to-end, start-to-end, start-to-end, etc. continuously until the target region is filled. " My understanding is, that there are two areas for spreadMethod, outside the circle determined by cx, cy,r and inside the circle determined by fx, fy, fr, respectively if the first stop offset is not 0. As long as the f-circle is inside the r-circle, there is no specific problem for spreadMethod. The order to realise the gradient does not matter for the visual effect. If the f-point is on the r-circle or close to it, one can get this interesting chaotic behaviour. The visual effect in some parts of the outer plain may depend more on numerical rounding problems than on the order the gradient is realised. Maybe if the f-circle is approximately on the r-circle, this can be used as a chaotic noise generator? If one allows to set the f-circle outside the r-circle, one has to define the order, the gradient has to be realised, including the spreadMethod. If one starts with the inner spreadMethod area, then going from f to r, followed by the spreadMethod for the area beyond r, the gradient part outside r can cover parts of the gradient, that belong to the case, that the f-circle is outside the r circle. If one starts with the area beyond r, going then from r to f with the gradient, followed for the spreadMethod for the area inside f, one gets the situation, that the 'f outside of r' part and the spreadMethod inside f covers parts of the gradients from r to f and the spreadMethod beyond r. Obviously one can start with the r to f or f to r areas as well, followed then by the inner spreadMethod area and the outer or vice versa. Alternatively one can start with inner/outer spreadMethod area and doing then the r to f or f to r area. 3 areas, but there can be self-intersection for the r to f as well, therefore 2* 3! = 12 options to define the order, the gradient has to be realised, if one allows f outside r, all of them can have a different visual result. Because for the values reflect and repeat the order can matter as well, for them there can be even more options, that have an effect. (It seems to have the reason to keep it simple for SVG 1.x, that this was excluded.) Remaining questions: * under which circumstances and scenarios it is useful to have such a self-cover or self-intersection of the gradient? * which order is more useful? * should the author have the choice of the order or should it be possible to switch inside and outside or the meaning of r and f (fr >= r)? * wouldn't it be useful for authors to set the spreadMethod for the inner part independently from the outer part? * maybe interesting as well to set (approximately) r=fr, cx=fx, cy=fy and to see what will happen with spreadMethod in real implementations ;o) OlafReceived on Tuesday, 4 September 2012 10:49:04 UTC

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