Re: New version of mesh branch.

Hi Tav,
> I don't have either Illustrator or Corel Draw.
Neither	do I, but I have a friend who let me use his ancient Illustrator 10.
>  * To edit a patch one seems to need two sets of control points. One set> to control the geometric shape of the patch and one set to control the> color spread. How does Illustrator handle this?
You	define your shape independent of any mesh, fill it with color and to turn it into a grad mesh you simply click the mesh tool and then click your shape, which automatically covered with a basic 2x2 mesh.Any	corner you click, you can define a color which automatically diffuses and the	control points associated with that point are activated. Editing the controlsdistorts the shape and the colors together. So if Illustrator uses two sets of controls, it's completely transparent to the user.
>  * How did you generate the right side image for bilinear_combos_compare.html?
Simple export as .jpg. I also exported the same mesh as SVG: /basicMesh2x2.svg
>  * Having a derivative of zero along the edge handles the case where the> color at the edge is at a maximum or minimum but we also need to> smoothly join patches where the color along the edge is in between. 
If I understand correctly, by "in between" you mean colors with arbitrary RGB components,	so let me just emphasize what I already wrote in my post:
"No	matter what color is at which corner, this configuration ensures the	derivative of the color change at all boundaries is zero."
And	that includes any color whatsoever.
>  (And the problem is more complicated when red, blue, and green all have> different profiles.)
The	configuration I suggest (degenerate Hermite + bilinear) doesn't really careif	the red, blue, and green all have different profiles. It will smooth colors at anyboundary, both the boundary where they start and the boundary where they end, regardless of their components profiles.Sorry Tav, but the following paragraph from your page (http://tavmjong.free.fr/blog/?p=316):
"Another case where it is impossible to obtain a smooth transition is when the different primary	colors (red, green, blue) have different profiles. In general, only the profile of one color can be made smooth."
Is no longer valid if colors are interpolated by the Hermite-bilinear combination. 
Following is a demo of the blue, magenta, and yellow sample from your page, compared with same colors interpolated by Hermite-linear combo: 
http://owl3d.com/tests/Gradient_Mesh/lerpHermite.html(fast production, inefficient messy code)
May	I suggest to test it with any imaginable colors to realize they are *always* smooth at *all* boundaries.
>  * I am rethinking our decision to use type 6 rather than type 7 meshes.
PDF	standard type 6 and type 7 differ only by the way they map the interpolated colors to the destination geometry. To interpolate the colors, both use bilinear interpolation which means both are inherently color-discontinuous at boundaries and	generally, this cannot be corrected by any of their mappings.
To be honest, I haven't read the PDF standard too deep, but if those typesdo not allow incorporating pre-bilinear smoothing interpolants, then I think the	rethinking should be to not use any of them.
>  * I am open to making SVG meshes use something like an interpolant> provided that::>	   3. There is a simple way to export them to PostScript/PDF.
???	I'm not sure I read this correctly :) Is this an SVG requirement?
Hello Jasper,
> I'd recommend borrowing the path syntax.:>  (I'm not sure whether it's worth allowing relative coordinates for> colors, but even that would be doable, and might sometimes make sense.)
I think latter remark is more realistic, path syntax is over-specified for colors and	I'm afraid the implementers will reject it. 
I think you'll get better traction if you consider keySplines. They carry all the	info you need - start slope, end slope and nicely curved inflection, andthe	implementers would love it because the algorithms are already inside the	UA's. Just for the record, the degenerate Hermite I suggest, is precisely equivalentto keySpline="1/3, 0, 2/3, 1".
I think also the designers will find it easy to edit: matching start slope of onekeySpline to the end slope of its predecessor is not so difficult even for thosewho	are less comfortable with math.
<linear/radialGradient	<stop stop-color="" offset="" keySpline=""
Please note this is the old, somewhat lame, definitely orphan, native gradient.The	keySpline define the interpolation from this stop-color to the next, and	UA's which are yet to support it, will just ignore it.
When the above implemented, with happy tears in my eyes, I'll be able to finally	visualize, while still alive, the gradient I dreamt about for so many cold, lonely nights: the ball/sphereGradient:
<radialGradient>	<stop offset="0" stop-color="aqua"  keySpline="1/3, 0, 2/3, 1/3" />                	<stop offset="1" stop-color="navy" />
As for the mesh:
<patch geometry="c..;c..;c..;c.." colors="..;..;..;.." 	keySplines="..;..;..;.." boundaries="..,..,..;..,..,..;..,..,..;..,..,.."
There is space for 4 keySplines, each for a boundary, and the lacuna value islinear (1/3, 1/3, 2/3, 2/3). Designers should be well educated in the spec aboutthe	different role of color keySplines as compared to the SMIL keySplines.
Here I have a proposal for easier designing: allow the most used keySplines to be referenced by names. Same like 'red' for the machine is equivalent to rgb(255,0,0) let, for example, 'linear' be equivalent to '1/3, 1/3, 2/3, 2/3'.
Most used keySplines are very few. From the top of my head:
linear (1/3, 1/3, 2/3, 2/3) Trivial.hermite	(1/3, 0, 2/3, 1) Best symmetric universal smoother there is.quadOut	(1/3, 2/3, 2/3, 1) ball/sphereGradient start from ball edge quadIn (1/3, 0, 2/3, 1/3) climb a ball with quadOut, go down with quadIn,slightly counter-intuitive, but this is the way it works. Look for the 0 slope.quadInOut (4/9 ,0 , 5/9, 1) not analytic but good approximation. Very useful for Lambertian concave-convex combo. Can	also be used as a symmetric smoother but is more "bulgier" than the	Hermite, thus pulls the interpolated colors farther to the center.

Back to mesh syntax.
"boundaries" is to inform the UA which boundary of this patch is shared with which boundary of another patch. Thus, "boundaries" can contain 1 to 4 semicolon-separated	triplets, each triplet is coma-separated.
First part of a triplet is the index of this patch boundary (0,1,2,3) that is shared.Second part is a reference to another patch in which the shared boundary is part of its geometry. Third part is the index of the shared boundary on the referenced patch.
If the third part is missing, it means the reference of the second part is directly to a cubic Bezier regardless if it is boundary of a patch. 
So for example: "0, url(#patch2), 2" means first boundary of this patch is sharedwith the third boundary of another patch with id="patch2" and "0, url(#patch2)"means first boundary of this patch is the path with id="patch2", which of course must be a cubic Bezier and M point replaced by last point of previous boundary.
Which brings us to the semicolons in "geometry". The	UA must be able to distinguish between a degenerate boundary, which must be explicitly described, and a missing boundary (;;) in which case it will find the missing geometry in a boundary referenced in "boundaries". Without	semicolons, the UA cannot tell which index boundary is missing.
Needless to say, this system allows describing any boundary only once.
Off	the scope of gradient mesh, the geometry/boundaries syntax can be adopted	to maps composed of many states/districts/neighborhoods. In maps of course, the number of boundaries will not be limited to 4 as also a single boundary will not be limited to cubic Bezier.

>  ...For example, if both interpolation types are cubic, then> essentially you could just allow a user to select colors per control> point (instead of only at the corners).
If those cubics are Beziers, which generally do not interpolate their control points,how	will you achieve precise control over the result color at control points?
But	if precise control over non-corner colors is not a requirement, then this iscertainly a fascinating feature: 16 different colors on a single patch(!) what a trip...
Regards,Israel