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

Re: [svg2] radialGradient @fr constraints

From: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>
Date: Tue, 04 Sep 2012 14:06:55 +0200
Message-ID: <5045EEDF.5030502@hccnet.nl>
To: www-svg@w3.org
On 04-09-12 12:48, Dr. Olaf Hoffmann wrote:
> 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.
> ...
> 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.

Yes and no. The spreadMethod can best be interpreted as what to do for
values of t outside the interval [0,1]. So if the zero-radius point (or
focus) is inside the circle, then you indeed have the areas you
specified. In other cases, there are two cones/wedges that get filled.

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

The order is effectively given already (in terms of the stop offset/t),
and all specifications that allow this agree on the same method (which I
have also used). Basically larger values of t are drawn on top of
smaller values. Essentially you're looking down on a 3D cone (with t
being the 3rd dimension).

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

The appearance of the gradient is COMPLETELY determined by specifying a
starting (t=0) circle, an ending (t=1) circle and a spread method (or
two if you want to be able to have a different one for either end), in
combination with the actual colour gradient of course. You're right that
there are lots of options, but this is simply a consequence of this
definition, it does not complicate either the specification or the

> Remaining questions:
> * under which circumstances and scenarios it is useful to have
> such a self-cover or self-intersection of the gradient?

Well, that's indeed a fair question.

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

Unless I'm completely missing your point, there are only two choices:
larger t over smaller t or smaller t over larger t. Given that they are
equivalent (if you want the other, simply swap the starting and ending
circle) and that larger t over smaller t is what has been used up to
now, I'd recommend simply going with larger t over smaller t.

> * wouldn't it be useful for authors to set the spreadMethod for the
> inner part independently from the outer part?

Possibly, PDF allows it, but I have no idea how often it is used. One of
the things you could do with this is create a cone that is truncated on
one side.

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

Ah, yes... That is definitely an interesting one. Technically, if they
are exactly equal, nothing should be drawn (all infinitely thin circles
are on top of each other). It's essentially a worse version of the
problem I showed in my post, and could be dealt with in much the same
way (specifically, the same measures suggested there would help solve
this problem as well). In a way the current SVG spec deals with it by
again enforcing that the focus should be contained within the circle, so
that instead of having two points on top of each other, conceptually we
have a point and an infinitely small circle around it.
Received on Tuesday, 4 September 2012 12:07:29 UTC

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