Re: [svgwg] Change arc grammar to coordinates rather than numbers and flags. (#755)

I think no.

The problem here is that arc is goofy, in a few different ways. The spec requires that rx ry be positive numbers and flags be either `0` or `1`. So it's `a rx ry theta flag flag ex ey` and since flags can only be 0 or 1. You're allowed to scrunch them. Creating an ex value that could be flagex or flagflagex. If the current grammar permits "a25,25 0 1125,25 z" there's not really much that could be done. It makes the easier form of parsing treating everything as `<command><float>*` kind of impossible.

There is a request to make arcs easier to actually write. So some grammar changed versions are certainly permitted. But, only requiring that there must be a wsp between the flags and between the flag and the coordinate value would make parsing that that valid. You could say rx and ry accept negative numbers too but they must take the absolute value of them and not use the error values and that would be inline with what many implementations already do.

There's a lot of different methods for implementing arcs for parameterizations, though and it's worth taking a look at.

1) SVG. Has the start and end points declared, and gives a sublist of parameters (rotation, rx, ry, large-arc flag and sweep-flag) that allow you to solve for the center and the direction of the arc sweep.

2) G-Code arc.  G02 and G03 arcs perform clockwise arc or counter-clockwise arcs. They have known startpoint and endpoint.  The arc is defined by _either_ `JI` relative offsets from the starting point to where the center of the arc is located. _or_ a given `R` (radius) value.  These have the advantage that actual users actually write them out by hand. But these arcs are only circular arcs. But then most all arcs people actually use are circular arcs. `G02 X2Y0 R2` is pretty hard to beat in compactness of parameters. `R r ex ey` can define (so long as start(x,y) is not coincident with end(x,y)) two arcs either a counter-clockwise one or a clockwise one, this can be decided based on the sign of the r value where positive r is clockwise and negative r is counterclockwise.

3) Unit circle, matrix, start, end, sweep. All ellipses can be defined by a matrix applied to a unit circle. Since the goal of many of these parameterizations is to define a circle or arc in some clever way, this goes into that pile. You define a matrix with the six values SVG uses. Then you have the start point which should be on this ellipse, you then define the end-point which should also be on the ellipse. And you define the value of t for the tau-radians of sweep with negative sweep meaning rotate counter clockwise.

4) Start, End, Center, Point-Rx, Point-Ry, sweep. You define the start point, end point, center point, the point at rx, which is to say located at t=0 tau and the point at ry which is the point located at t = .25tau. The rx value is the distance between center and prx and the ry value is the distance between the center and pry. The ellipse rotation is the angle of prx from center. The sign of the sweep value controls whether this is clockwise sweep or counter-clockwise sweep. --- The advantage here is everything is a point. You can store it as a bunch of points and multiply them by a matrix.

5) Start, Edge Point, End. With three defined non-coincident points there is 1 circle that goes through all three of those points. The start point, and end point are two such points. The third point is between them on the circular arc. `R px py ex ey` would thusly define the arc. Which would be required to be circular.

6) Start, edge1, edge2, edge3, End This would seem rather like a quintic bezier curve looking but since all ellipses are members of the conic sections family you can define them with the equation Ax^2 + Bxy +Cy^2 + Dx + Ey + F = 0 and you could just set F to 1 and solve the system of equations so in theory any five non-coincident points define an ellipse. There might not be a solution or it could be a hyperbola or something but you could just list 3 points on the arc between the start and end points and you'd be able to solve the ellipse and curve accordingly. (see https://sarcasticresonance.wordpress.com/2012/05/14/how-many-points-does-it-take-to-define/  )

But, none of this goes back in time and requires that flags be numbers, or require white space. I will say however I doubt there are very many svgs that wrote their code that way. It likely won't break many of them. I was unaware it was a thing until the I hit the w3c test and checked the BNF.

I will say 2 and 5 might be worth looking into. A command for a simple and readable arc, especially one like 5 where you can literally scale it by a matrix without much trouble might be kinda nice. I've also sort of liked the idea in 3 to express a path matrix. So Xa b c d e f to append a path matrix. That's how bearing would actually have been implemented. Bearing would mean `rotate(b, current_x, current_y)` And really somethings only use paths to basically express everything and they can't actually express the matrices.

-- 
GitHub Notification of comment by tatarize
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/755#issuecomment-562625550 using your GitHub account

Received on Friday, 6 December 2019 15:47:32 UTC