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

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

Received on Monday, 3 December 2012 19:18:09 UTC