Re: [svg2] radialGradient @fr constraints

On Sep 4, 2012, at 9:08 AM, "Rik Cabanier" <cabanier@gmail.com<mailto:cabanier@gmail.com>> wrote:



On Tue, Sep 4, 2012 at 5:06 AM, Jasper van de Gronde <th.v.d.gronde@hccnet.nl<mailto: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 filled.
which is at odds with the new behavior.

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

I agree, as pointed before the text was correct before the changes and just doesn't reflect the necessary changes. So it needs to be updated as well. A least if we allow focal points (with radius) to be outside of the gradient radius.

Dirk


Rik

1: chapter 8.7.4.5.4 in http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/pdf/pdfs/PDF32000_2008.pdf

2: http://www.w3.org/TR/SVG/pservers.html