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

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 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.htmlReceived on Tuesday, 4 September 2012 16:07:27 UTC

*
This archive was generated by hypermail 2.3.1
: Wednesday, 7 January 2015 15:29:52 UTC
*