# stroke-linejoin="arcs" Classic List Threaded 5 messages Open this post in threaded view
|

## stroke-linejoin="arcs"

 Hey guys,I am a computer graphics researcher and have been looking into the new "arcs" stroke-linejoin proposal for SVG 2. Is the specification complete? If so, I can imagine many developers will have trouble sorting out the missing details. Take at look at 12.5.8 and figure 13 athttp://www.w3.org/TR/SVG2/painting.html#CurvatureCalculationIt seems to me that easiest way to specify the center of the circle is relative to point P, and not relative to points P1 and P2. This is because we are offsetting the osculating circles to the path at P (at each side). The offset circle has the same center as the osculating circle. If the normals of the path at P are N1 and N2 and the curvatures are k1 and k2, the center is always at P + N1/k1 and P + N2/k2, regardless of the stroke-width.Once the center is fixed, we need the radius. Here, I believe the correct formula is abs(1/k - 0.5 stroke-width). Look at figure 13. If you increase the stroke width on and on, at some point P1 will cross the center of Aoutside. You need the abs() for this case. It is the sign of the curvature that tells whether we should add or subtract 0.5 stroke-width to the radius of curvature. The abs() allows us to unify everything in a single case.There also seems to be missing information on the arcs that make up the join:" If the two circles (or circle and line) intersect, the line join region is defined by the lines that connect P with P1 and P2 and the arcs defined by the circles (or arc and line) between the closest intersection point to P, and P1 and P2. "In the case where both curvatures are positive and both radii of curvature are smaller than 0.5 stroke-width, the arcs that connect P1 to P4 and P4 to P2 are CCW (and can easily span more than 180 degrees). In all other cases, the arcs seem to be CW.There is an additional interesting corner case. The documentation mentions the cases where the points do not intersect and when both curvatures are zero, in which case we should fall back to miterclip. However, when either curvature is +/- infinite (or very large magnitude), it is better to revert to round instead.There seems to be a a typo in "For a line: the curvature is infinite." I think you mean that the curvature is zero, right?At any rate, this is just a heads up and a request for clarifications. The more explicit the documentation is, the fewer confused people like me there will be.Kind regards,Diego
Open this post in threaded view
|

## Re: stroke-linejoin="arcs"

Open this post in threaded view
|

## Re: stroke-linejoin="arcs"

 Dear Tav,I assumed the right-hand convention for the normals. Take the tangent direction at a point P(t) while moving along the segment. Call it T(t). Rotate it CCW by 90 degrees and normalize to produce N(t). Now compute signed curvature κ(t) as usual. The center of the osculating circle is at P(t) + N(t)/k(t). As long as the tangent direction and curvature have been computed consistently (i.e., traversing the curve in consistent directions), the formula should work, no? Where is the ambiguity? The formulas do not change regardless of whether the join is to the right or left of the path.I think we have a few cases here, depending on signed curvatures of the two connecting segments. In order of precedence:1) If either curvature is -∞, we revert to the round join.2) If both curvatures are in (-∞​, 0], then the offset osculating "circles" intersect and we are golden. Quotes are because these circles could degenerate to lines, but this is no trouble.3) If one curvature is in (-∞​, 0] and the other is in (0, 2/w), where w is the stroke width, the offset osculating circles may or may not intersect. This case is problematic because, according to the proposal, we don't have a continuous behavior here. Reverting back to miter when no intersection is found will basically create a pop. Perhaps we should instead take the positive curvature and reduce it until the circles are tangent? At least this would create a continuous behavior more in the line of what SVG does in other cases...4) If either curvature is in [2/w, +∞​], the offset osculating circles may or may not intersect. However, the intersection is *not* meaningful, because the offset osculating circle does not correspond to the offset stroke. It is as though you are offsetting a circle by more than its radius. Only the outer boundary matters. The inner boundary simply disappears. It doesn't make sense to intersect inner boundaries because they are not part of the offset path at all.For some reason, I can't load the SVG files you linked to. (Subscripts in a link?)As for your blog, can I get the SVG files for these cool examples you show?Kind regards,Diego​