Example where offsetTrail does not work as expected

[byorgey]

pts = map p2 [(0,0), (2,3), (5,-2), (-4,1), (0,3)]

s :: Located (Trail R2)
s = cubicSpline False pts

s' = offsetTrail 1 s

stroking s' results in

[byorgey]

More exploration:

{-# LANGUAGE FlexibleContexts          #-}
{-# LANGUAGE GADTs                     #-}
{-# LANGUAGE NoMonomorphismRestriction #-}
{-# LANGUAGE TypeFamilies              #-}
{-# LANGUAGE ViewPatterns              #-}

import           Diagrams.Backend.SVG.CmdLine
import           Diagrams.Prelude
import           Diagrams.Tangent
import           Diagrams.TwoD.Offset

pts = map p2 [(0,0), (2,3), (5,-2), (-4,1), (0,3)]

s :: Located (Trail R2)
s = cubicSpline False pts

segs :: [Located (Segment Closed R2)]
segs = locatedTrailSegments s

segs' :: [Located (Trail R2)]
segs' = map (bindLoc (offsetSegment stdTolerance 1)) segs

dia = (mconcat . map strokeLocTrail $ segs') <> strokeLocTrail s

main = defaultMain (dia # lw 0.05)

locatedTrailSegments :: (InnerSpace v, OrderedField (Scalar v))
                     => Located (Trail v) -> [Located (Segment Closed v)]
locatedTrailSegments t = zipWith at (trailSegments (unLoc t)) (trailVertices t)

bindLoc :: (Transformable b, V a ~ V b) => (a -> b) -> Located a -> b
bindLoc f = join' . mapLoc f
  where
    join' (viewLoc -> (p,a)) = translate (p .-. origin) a

generates

[fryguybob]

There are several bad things going on here. The long lines are due to the trace giving a bogus intersection that is clearly beyond the limit of possible intersections. It is doing this because it is given nearly identical lines because offsetSegment seems to be subdividing all the way to epsilon.

[fryguybob]

The default epsilon given is too small. I think we need to make epsilon relative to the given radius. Any thoughts?

[byorgey]

Whatever works. I don't have a good sense of what the "right thing" to do is.

[fryguybob]

I did not mean to close the issue -- just mention it. The epsilon issue is addressed, but what still remains is when offset segments that are nearly parallel are joined we get bogus miter join points.

[fryguybob]

I was hoping that switching to a more common definition of miter limit, but that has some numerical instability in another direction. I will have to look into getting intersections with (of just lines) with some error bound so we can solve this better.