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

Re: [svg2] radialGradient @fr constraints

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 4 Sep 2012 09:06:56 -0700
Message-ID: <CAGN7qDC-gCLS+nMcy_xYM9Z7ROMYJj6VgHti8rWaqHj_tf3cmQ@mail.gmail.com>
To: Jasper van de Gronde <th.v.d.gronde@hccnet.nl>
Cc: www-svg@w3.org
On Tue, Sep 4, 2012 at 5:06 AM, Jasper van de Gronde <
th.v.d.gronde@hccnet.nl> wrote:

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

I have seen a couple of exotic cases where they were used, but they are
very rare.
I don't not believe that any of our creative applications generate them.

> > * 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.
The PDF and Postscript reference manuals specify how to use circles to
create radial gradients.
They also specify how the extend colors are generated which results in a
cone. [1]

The SVG spec does not specify any of this.[2]
We should update this page to clarify the behavior. As Dr OIaf rightly
points out, the current spec says:

Possible values are: 'pad', which says to use the terminal colors of the
gradient to* fill the remainder of the target region*, 'reflect', which
says to reflect the gradient pattern start-to-end, end-to-start,
start-to-end, etc. continuously *until the target rectangle is filled*, and
repeat, which says to repeat the gradient pattern start-to-end,
start-to-end, start-to-end, etc. continuously *until the target region is

which is at odds with the new behavior.

We also need to call out what happens with alpha once the circles start
I think use expectation is that the gradient does not interact with itself.


1: chapter in

2: http://www.w3.org/TR/SVG/pservers.html
Received on Tuesday, 4 September 2012 16:07:27 UTC

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