...speaking of connecting lines (but otherwise unconnected), I'm creating some SVG source with externally calculated coordinates, plugged into a static file... (I'm not looking for adding inline/external javascript, or similar. I'm fine-tuning the drawing coordinates, still, but once I've done that there's no reason to do more work on the pathing.)

For some bits, I have what would basically be (in line-segments)

`<path d="M X1 Y1 X2 Y2 X3 Y3" />` (all absolute positions, with actual numeric values instead of '[X|Y][1|2|3]'... move to a 'P1' of "X1 Y1" and then implicitly draw the line to P2 and then another onward to P3).

If the three points are calculated as being near-enough colinear[1], then it's good enough to

`d="M X1 Y1 X3 Y3"`, but otherwise I'd rather use an arc of the circle that passes through the three Ps. Right now I'm using the sequence

`d="M X1 Y1 A r r 0 0 0 X3 Y3"` ('A' is the Arc command, rx==ry so two 'r's, then zero rotation necessary, short-arc (second 0) and, because of the way it's sorted I can currently guarantee that it's the same handedness of solution (third 0) on the way to the end coordinates). With the expectation that I can

`d="M X1 Y1 A r r 0 0 0 X2 Y2"` (or use as part of a longer path) just to pen the exact same path/boundary but only to the midpoint, or

`"... X3 Y3 A r r 0 0 1 X2 Y2 ..."` on the differently partial 'reverse' path, and yet follow the same P1->P3 curve.

But I'm getting inconsistent responses to the 'r's I'm giving.

I've tried working it out[3], but for self-similar triples (translated/rotated, but otherwise congruous) I'm finding I have to manually tune the value completely differently to what I

*think* my calculus suggests until it renders aesthetically and visually most correct-looking. So it's awkward. Or I've messed something up/misunderstood the syntax.

I perhaps could use

`"... X1 Y1 Q XC YC X3 Y3 ..."` for a single-controlpoint bezier curve, but XC YC would need to be an away-from the circle-centre adjustment of the X2 Y2 (often close-enough the curve midpoint to not worry too much about skew) by some factor or function of the true radius so that the line passes over P2, or within the line-width of it. And

`"... X1 Y1 Q XC YC X2 Y2 ..."` /

`"... X3 Y3 Q XC YC X2 Y2 ..."` would need entirely new (X|Y)Cs derived from calculated points P1.5 and P2.5. Even if the handedness of the curve would still then be self-evident without having to flip the given flag if reversing the sequence. Additionally, I could just build up a poly-bezier (shortcut with successive "T" path instruction(s)) to get P1->2->3 matching any other Pn->m that should coincide it or part of it.

Or maybe use the double-controlpoint bezier ("C" code, with or without its "S"-continuation). But I can even less work out how to derive all the (X|Y)C(1|2)s that would give a sufficiently circlelike path from that approach.

So... Does anyone have the same fetish as me for (semi-)handcrafting SVG, and perhaps know of a trick I may have missed/messed up along the way? I'm clearly more used to non-curving segments, as you can tell, or yer actual full circles dotted around, filled or in outline.

[1] I'm arctanning the angles of each segment, and if the values of the two differs less than a convenient value (currently 0.1, of the radian-computation; I may well adjust that threshold[2], but it currently nicely delineates the cluster of states) then it's straight-enough for me!

[2] It's less problematic than (for example) working out the y=mx+c constants and comparing the 'm's, given the non-linearity of relative magnitude vs relative combined orientation and tendency to go to undefinable/infinite for vertical lines. And, though I don't have acute angles (doubling back), I can trap that if necessary.

[3] Effectively doing the divider/straight-edge method. Midpointing P1->2 and P2->3, sending off perpendiculars, calculating the crossing coordinate that'd be the circle centre PC and using the magnitude of |P[1..3]-PC| as what I understand would be the value of rx and ry (which I've checked isn't being taken as an absolute coordinate).