- From: tatarize via GitHub <sysbot+gh@w3.org>
- Date: Fri, 08 May 2020 23:08:32 +0000
- To: public-svg-issues@w3.org
> Note that the commands "R"/"r" are already reserved for another cubic spline in the current draft I'm pretty sure the Catmull-Rom and Bearing aren't going to make it into the full spec. No sense letting the prime real-estate of R/r go to something that won't get implemented anywhere. > Note that for circular arcs, you don't need three on-curve points, only two points are sufficient No. You need at least three points. A start, end, and some intermediate point. There are otherwise infinitely many circular arcs that can pass through two points. You could use a matrix to convert a circular arc into any elliptical arc, but those apply to the whole path, and you'd need to make an isolated segment and apply the matrix etc. And it certainly wouldn't get easier to draw. The majority of the arcs we want to draw are circular arcs and the SVG grammar here is convoluted. Arc are a very weird special case, but the circular arcs would be a way more similar to the other path segments, would cover most of the use cases, and would be easy to implement by hand. Hitting a few of the requested arc modifications. > So I agree that we should have a "O"/"o" (circular arcto) or "E"/"e" (elliptic arcto) defined just by two or three on-point curves O/o look too similar to 0 and E/e indicates the mantissa of floating point number. > or by a sweep flag (from which the orientation can also be determined); One of the issues and reasons for my suggestion is that the A/a arcs are annoying with their various flags. If you can't specify the shape purely by points, you likely shouldn't have that shape. > The "O"/"o" is then a shorthand for ellipse, but with two additional parameters (opposite-point [start-angle [end-angle]]). The specifications of optional grammar isn't something found elsewhere in the path spec either. I daresay it's a problem for your suggestion #797 too. All grammar found elsewhere requires all options given, this is helpful with parsing. But, allows for multiple commands with the same path command so they are all specified `Q (cx cy ex ey)+` where you have a set series of exact numbers of points. Since you know that L takes one point, if it's given 3 that's 3 commands. You add option values and that goes out the window. > We should have a way to indicate that the next path fragment will draw a marker or not at the initial or final position of the fragment: My proposal would have a marker at the medial point (though maybe not if coincident with the start point). So you could specify it anywhere you want along the arc. I also permitted the special case of the coincident medial point to permit a smooth arc largely going with the understanding that the directionality would need to be tracked with regards to markers anyway. -- GitHub Notification of comment by tatarize Please view or discuss this issue at https://github.com/w3c/svgwg/issues/767#issuecomment-626057260 using your GitHub account
Received on Friday, 8 May 2020 23:08:34 UTC