From: Tavmjong Bah <tav.w3c@gmail.com>

Date: Wed, 13 Jan 2016 16:49:38 +0100

Message-ID: <1452700178.10405.9.camel@gmail.com>

To: Diego Nehab <diego.nehab@gmail.com>, www-svg@w3.org

Date: Wed, 13 Jan 2016 16:49:38 +0100

Message-ID: <1452700178.10405.9.camel@gmail.com>

To: Diego Nehab <diego.nehab@gmail.com>, www-svg@w3.org

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

*
This archive was generated by hypermail 2.3.1
: Wednesday, 8 March 2017 09:47:43 UTC
*