I'm assuming (perhaps incorrectly) that it's only SVG amongst our current
backends that fills open paths. I'm basing this on the fact the the others
all render the backend-tests correctly. If this is correct we only have to
worry about whether transparent fill == no fill for backends we do not yet
have, also  it seems a shame to have to reorganize and add complexity to
our code. Unless of course this is the right thing to do irrespective of
this problem.

I think the extra SVG nodes could be removed in an optimization pass on the
RTree so I'm not too worried about this one, since we plan on optimizing
the RTree anyway.

Lastly, somehow I feel that having to add an RTree -> RTree pass for
reasons other than optimization, may signal a defect in design, my
intuition is that the issue should be handled earlier in the process. This
is just my own opinion -  I have no formal way to back it up.


On Wed, Nov 27, 2013 at 2:42 PM, Brent Yorgey <notifications@github.com>wrote:

> In src/Diagrams/TwoD/Path.hs:
>
> > @@ -171,9 +174,9 @@ instance Renderable (Path R2) b => TrailLike (QDiagram b R2 Any) where
> >  --   ... }@ syntax may be used.
> >  stroke' :: (Renderable (Path R2) b, IsName a) => StrokeOpts a -> Path R2 -> Diagram b R2
> >  stroke' opts path
> > -  | null (pLines ^. unwrapped) =           mkP pLoops
> > -  | null (pLoops ^. unwrapped) = mkP pLines
> > -  | otherwise                   = mkP pLines <> mkP pLoops
> > +  | null (pLines ^. unwrapped) =  mkP pLoops
> > +  | null (pLoops ^. unwrapped) =  fcA transparent $ mkP pLines
>
> The alternative I was thinking about was to add an RTree -> RTree pass
> during compilation which splits and removes fill attributes as appropriate.
> However, Jeff correctly points out that given the way we currently have
> things organized, this would mean that the compilation code diagrams-corewould have to depend on attributes defined in
> diagrams-lib. We would either have to move some attributes into
> diagrams-core (seems wrong), or move the compilation code into
> diagrams-lib --- which actually might be the right thing to do, I am not
> sure.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/diagrams/diagrams-lib/pull/141/files#r7967673>
> .
>