- From: Doug Schepers <schepers@w3.org>
- Date: Wed, 14 Jul 2010 18:26:26 -0400
- To: Dave Crossland <dave@lab6.com>
- CC: www-svg@w3.org
Hi, Dave- Dave Crossland wrote (on 7/14/10 11:47 AM): > Responding to the minutes: > On 13 July 2010 22:31, Anthony Grasso<anthony.grasso@cisra.canon.com.au> wrote: >> >> Catmull-Rom curves >> <shepazu> http://schepers.cc/?p=243 >> >> DS: If you look at that link. If you compare his spiro curves and mine >> ... his look a lot better >> ... not sure how he does that > > But its so simple. Here's http://levien.com/phd/thesis.pdf is 191 > pages of Berkeley math PhD thesis to explain! ;p Ah, pretty pictures! However, the prose was marred by some squiggly nonsense shapes that looked something like this: "1 2 3 4 5 6 7 8 9 0". I skimmed the paper, and read the intro and conclusion; the section on interpolation masters (p. 158, Figures 10.9 and 10.10) was particularly interesting. I think you and I talked about this in Brussels, and I wonder how well Catmull-Rom curves would perform in this regard? >> ... the advantage of the Cutmull-Rom curve if you just give a set of points >> ... It looks like with Spiro curves points have a different characteristic > > Spiro has 5 kinds of points. So, in that respect, spiro is more akin to a multiple-command path segment than to one particular command such as a cubic Bézier. In other words, my experiment with [1] using a combination of (simulated) Catmull-Rom curves combined with Linetos is rather similar to spiro. >> ... the problem with extending path is it is no longer backwards compatible > > I suggest that authoring tools provide fallback Bezier paths for > backwards compatibility; Raph Levien authored excellent optimised > Bezier conversion programs to do this which are GPL as part of the > "ppedit" tool suite. http://levien.com/garden/ppedit/ Any kind of "in-file fallback" will always be lacking: 1) it increases the filesize, often dramatically (double or more) 2) it will not respond dynamically in the same was as the extension, meaning it is only good for completely static functionality 3) it relies upon some sort of fallback mechanism, which would have to be defined for this case 4) it may confusing or unintuitive for people to edit the file by hand Fortunately, we are in an enviable position. SVG, while mature, is not yet so widely deployed that extensions made now will cause much harm, since they won't affect past content, and most significant implementations (authoring tools, browsers, and toolkits) are active projects and have shown evidence that they are willing to adapt. >> ... we need to figure out what the syntax would be > > Raph made a simple s-exp syntax for his ppedit prototype That does seem to be similar in general nature to the SVG path description... a set of different path commands to achieve different effects. >> DS: We need to talk to Ralph Levien >> ... about using his method >> ... we need to find out if it can be a royalty free algorithm that we can put in SVG >> ED: Do these curves have any license issues related to them? >> DS: I didn't find any problems with their licencing Erik's question about licensing was for the Catmull-Rom curves, not spiro. > Raph has a USA software idea patent on Spiro, with a GPL grant, Right, I'd seen that... that's why we will need to talk to him. However, he seems like a reasonable guy. :) [1] http://schepers.cc/?p=243#spiro-a Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Received on Wednesday, 14 July 2010 22:26:28 UTC