W3C home > Mailing lists > Public > www-svg@w3.org > September 2012

Re: [svg2] radialGradient @fr constraints

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

 Use the terminal colors of the gradient to fill the remainder of the target 
 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 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)

Received on Tuesday, 4 September 2012 10:49:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:37 UTC