Re: [svgwg] Add circular arc path command 'R'. (#767)

> > Note also that another simple way to specify an elliptical arc is by its tangeants: exactly like if it was a quadratic spline
> 
> The problem here is that it's adding additional classes of information. The main oomph behind my proposal here is that it's a simplified and more consistent type of arc. It's specified entirely of points and you can just make them by hand. And it requires no additional classes of information. In fact they can be implemented quite easily by utilizing the existing Arc_to code. All the commands in paths are simple and specified entirely of points and the type of thing being specified, except arc which is pretty convoluted. Circular arcs would be less convoluted and would match the vast majority of the use cases for arcs.
> 
> I don't think Catmull or Bearing will make the cut.

Bearing (also skewing and scaling) causes a difficulty: it implies a change of coordinate system inside the path. As well it changed the origin of abosolute coordinates (it has no effect on relative coordinates that are always relative to the last current point in the existing coordinate system). But there's no way to save it and restore it for local curves: it would be "fun" to have the "<" operation for pushing on a stack the current coordinate system, before changing the bearing (or skewing or scaling), and the ">" to pop the coordinate system back to what it was before "<".

> It's way harder implementation for very little benefit.

There's limitation already in the path syntax which is limited to 2D coordinates. Just adding the parentheses acound coordinates allows arbitrary dimensions, and what I describe is just maintaining the path as a set of points (independantly of their actual number of dimension, which is implicitly extensible to higher dimensions with missing coordinates set to 0) with a few additional flag letters that an, be used to determine their type (control point or on-curve, and type of control point for describing the type of curve).

As well what I describe allows musch easier extension to other curves. This creates a new kind of "generic" path that would work with all dimensions and would allow arbitrarily changes of curve types, and many more curve types, including Bezier with hiher degree than just cubic, or other parametrization (e.g. Catmul-Rom instead of Bezier for cubic splines; note that Catmul-Rom, in all its alpha-variants from 0 to 1, is equivalent to a cubic Bezier, the parametrization being just different for control points)

Circular and elliptical arcs are quite difficult to parameterize with non obvious flags: my approach is simpler: just use control points (as if elliptical arcs were quadratic Bezier: place the control points for the elliptical at the corner of a tangeant rectangle: use a Bearing command if needed to rotate the ellipse easily before placing the elliptic arc command and the control points in successive corners, or just one control point for the first corner and a angle range for arcs of circles, assuming that you can also "scale" the coordinate system by indicating scaling factors as a vector with arbitrary dimension).

Adding more dimensions also allows other shapes: for example computing a 3D-to-2D perspective can be done by adding only the third dimension ans still using linear arithmetic for all transforms, except the final projection from 3D to 2D which divides the 3D vector by its norm and then drops/ignores the 3rd dimension. And with 3D-to-2D perspective, you have perfectly defined 2D hyperbolic curves...

It's clear that existing Arc/arc is badly parameterized: I much prefer arcs parameterized as if they were quadratic Bezier splines (with additional benefit: you can easily estimate a bounding rectangle, this is why the C-Rom cubic is sometimes prefered to the cubic Bezier, that are harder to compute to estimate a bounding rectangle because it can produce local cups and self-intersections that are very hard to locate precizely for correctly filling surfaces, while C-Rom splines don't have this defect for alpha=0.5; but C-Rom's are less precise than Bezier and don't necessrily reduce the number of control points and on-curve points needed).


-- 
GitHub Notification of comment by verdy-p
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/767#issuecomment-626066417 using your GitHub account

Received on Friday, 8 May 2020 23:47:49 UTC