Re: stroke-linejoin="arcs"

Hi Diego,

Sorry it has taken me so long to reply...

On Tue, 2015-12-01 at 13:54 -0200, Diego Nehab wrote:
> Dear Tav,
> 
> I assumed the right-hand convention for the normals.

SVG actually uses a left-handed coordinate system as y point down...
but that doesn't affect the discussion below.

> 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.

Yes, for calculating the center of the circle. But not for calculating
the offset radii. Try reversing 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.

This means the radius is zero. That can't happen for Bezier curves. I
suppose it could happen if an elliptical curve was flat. In any case, I
don't think this needs to be special cased since the offset path will
have a radius of w/2.

> 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.

Yes, this should always work, offset radii greater than w/2.

> 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...

This is an interesting idea but as far as I can tell it requires
solving a quartic equation. I tried just increasing the smaller circle
until there is an intersection. See the animation in the web page
below.

> 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.

I'm not 100% sure of what you are saying here but of course inner
boundaries are not relevant here.

> For some reason, I can't load the SVG files you linked to.
> (Subscripts in a link?)

Subscripts? Are you perhaps a tex user?

> As for your blog, can I get the SVG files for these cool examples you
> show?

Most if the images are SVG files. Inkscape trunk has a "Join" LPE which
implements the arcs line-join. It's a bit buggy but it gives quite
useful feedback. By setting the stroke color different than the fill
color one can see the generated offset path.

I've prepared a web page with some studies of line joins. I look at
several options for fallbacks for the 'arcs' line join and at the
bottom there is an exhaustive diagram of all the different possible
combinations of curvatures relative to stroke widths. See:

 http://tavmjong.free.fr/SVG/LINEJOIN_STUDY/

Tav


> Kind regards,
> Diego
>

Received on Wednesday, 13 January 2016 15:50:11 UTC