W3C home > Mailing lists > Public > www-svg@w3.org > July 2010

Re: Scheper's Catmull-Rom curves, and Spiro curves

From: Doug Schepers <schepers@w3.org>
Date: Wed, 14 Jul 2010 18:26:26 -0400
Message-ID: <4C3E3992.7000501@w3.org>
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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:45 GMT