Re: SVG2 - suggestion for a new path command to close a subpath smoothly

Hi,

It would be good to see the formula's that derive the strength of the
control points. Even better would be a small library that implements them
so  people can experiment with the results.
Thinking about it some more, I'm less concerned with arc since the
'direction' of the last control point is probably constant with respect to
precision.
We'd still need to specify what would happen to Catmull-Rom.

On Mon, Dec 3, 2012 at 11:02 AM, Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>wrote:

> Rik Cabanier:
> ...
> >
> > Your proposal talks about the 'direction' of the control point, but not
> its
> > 'strenght' (= how far is it from the anchor point). Maybe if you can spec
> > that our somehow, we can mitigate this particular issue.
>
> This applies for the commands S and T as well. There is a
> missing free parameter for them as well. This is assumed to be '1' for
> S and T, if the direction is determined from the control points 'naively'.
> Because this 'ß' duplicates mainly the functionality of S followed by Z,
> one should use here '1' as well.
> If the ACTION-3085 (requirement for smooth interpolation between points)
> is realised, it will have to implicate much more somehow free parameters
> than S or T.
>
> In my (german) tutorial about SVG I have formulas how to determine the
> same control points as the S commands and how to use this algorithm to
> close a path smoothly with the same type of curve, corresponding
> descriptions
> can be found in the (german) wikibook about SVG:
>
> http://de.wikibooks.org/wiki/SVG/_Pfade#Kubische_Kurvenst.C3.BCcke:_C.2C_c.2C_S.2C_s
> (the PNG-preview images by the way show, what happens, if one relies on
> graphic libraries - wikipedia/wikimedia/wikibooks etc use librsvg - and it
> is
> always a funny surprise to see the results ;o)
>
> If required, I can translate the essential things tomorrow -
> the formulars are not very surprising or exciting from my point of view ;o)
>
>
> ...
> >In my original email I forgot to mention the 'arc' related commands. Since
> >the spec doesn't describe how those are broken into beziers, this new
> >command can't work the same across UA's.
>
> In my tutorial I have scripts as well, that do such approximations of
> elliptical arcs with cubic curves.
> An someone reused it already in a library including the conversion
> to SVG commands - at least this reuser was pretty sure, that the
> approximation is good enough not to see the difference...
> Well, I'm more careful and the way I write such scripts is
> not optimised for fast computing - obviously no problem for
> this reuser as well ;o)
> To see a good approach to determine how many cubic curves
> at least have to be used to meet a required accuracy would be
> pretty interesting.
>
> However, the general requirement is only, that there are
> enough cubic or even only straight lines in the approximation,
> that the error of the approximation is below one device pixel,
> if we take the general rule from SVG tiny.
> If this is met, it is not really important, how a user agent
> gets this accuracy with the approximation.
> If it does not meet this requirement, it fails anyway in a
> visible way.
>
>
> Olaf
>
>
>
>