Re: [svg2] radialGradient @fr constraints

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

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