Re: SVG2 CR - Catmull-Rom curve commands missing??

Doug Schepers:
...

> 
> If the browser makers express willingness to implement it, I'd be
> willing to write a spec just for that feature; that spec text could be
> published on its own, or folded into a larger SVG2.1 spec, or whatever.
> We'd also need tests for the feature; I could help with those, too,
> though I'd like help on that.

This would be a subset for the path d attribute value.
I think, it is not a good idea to modify this somewhere else as in a major 
version of SVG as version 2.
There are other requirements to extend the path syntax.
This should be all in one major SVG version to avoid incompatibilities
each new year of with each new subversion.
Authors and users need reliability on such a core feature as the path d 
attribute for a long time.
Else there would always be the question, do the users really see, what authors 
noted.
Respectively there is a need to expose every version number of SVG to the 
users in user-agents older than the date of the SVG recommendation, a document 
refers to, else such new features in subversions or moduls become almost 
irrelevant an unusable for authors for a long time.

> 
...

> 
> The upside to using Catmull-Rom curves is that they provide pretty
> intuitive curves for a large range of variables (assuming you imply a
> duplicate starting point and ending point to the formula, and have a
> modest tension parameter), are fairly fast to compute (good for
> rendering and animation performance), and are widely used in computer
> graphics libraries; a downside is that the penultimate curve segment
> does change its shape when you add another point, but perhaps that's
> unavoidable.

This is similar to the combination of Q and T commands.
If one reduces the number of parameters, one does not have the complete 
control anymore - here the modifications are not completely local anymore.

But of course, there are interpolation methods, which ensure, that a change of 
one point has only local influence on the curve to the next few given points.
Doing this one still has to add some information, how to start and to end, 
respectively how to connect smoothly a closed subpath, what should be possible 
as well with this features to get a useful simplification for authors.

If authors really want the complete control, they still can only use C 
commands with own calculations.
Such smooth curves are mainly userful for authors searching for a fast and 
simple solution. They will surely accept, that they will not have the complete 
control, if they use such a set of commands.

I think, for many authors it would be already ok to have something like the 
combination C and S, but without the additional control point (without tension 
parameter) to get smooth curves without calculation and without control or 
only with two control points (additional parameters) for the complete subpath. 



Charles Lamont:

>I am another disappointed long-term want-to-user of curve fitting, but I
>have thought for some time the WG is right to try to get SVG2 out as
>soon as possible, containing whatever.
>
>Version 2 has already been far too long in the making, and
>recommendation of the much more detailed and precise spec will
>demonstrate that there is still a flicker of life in the project. Long
>awaited, and very necessary enhancements can follow when implementers
>see that some sort of progress is actually occuring.

I think, it is the completely wrong message to authors, users and implementors 
to publish such a draft with almost no new features as a major version or as a 
recommendation at all.
There is no need for this without all these features, once identified to be 
required for version 2.
Those are the reason, why there was a need for version 2 at all.
Without them this version is a document without any reason or purpose.
Simply nobody needs such an empty version, maybe except the SVG working group 
members to show existence.

Olaf

Received on Monday, 12 November 2018 22:34:39 UTC