Re: [svgwg] consider more involved path shapes (#754)

@dalboris, thanks for the links, I found them to be quite insightful!

@Doktorchen, I appreciate the idea, but I feel like the problem that arrives from it is that, then, from my understanding, there is no way to reference to a defined path segment across files, which is important to my specific use‐case, since my image is split across multiple files before minification.

---

I have been thinking about how to incorporate point/edge sharing in SVG cleanly, and I honestly couldn’t think of a satisfying design.

The main obstacles I faced were that it would complicate the possibility for [outset and inset strokes][strokes spec], as well as that they are difficult to represent intuitively for authors. The later problem is not so true for Figma and VGC Illustration, since they are graphical tools rather than a textual image format.

[strokes spec]: https://svgwg.org/specs/strokes

The rationale of “proper stroke linejoin” sounds a little unconvincing to me, since a linejoin is only applicable for angles greater than 180 degrees, of which there can be at most one if two or more line segments share a terminal point.

As such, these line segments could all simply end at the same point with a “butt” linecap, except for the potential two lines that form an angle greater than 180 degrees, which would actually be connected.

With path fragments, it’s possible to imagine that it’s easy to separate all path segments without an intersection, and then: (1) use various paths containing `url()` references to define the stroke of the shape, and (2) use a distinct set of paths with `url()` references that define the fill paints of the shape.

@dalboris’s concern with animation is definitely an interesting one, but it seems to me that involved animations are outside of the scope of SVG.

The conclusion I reached is that, to me, it’s important to discern the objectives of image editors from the objectives of SVG. While vector networks and VGC are definitely interesting for graphical software, I don’t think they make sense in SVG as a primitive. Rather, I feel like these kinds of approaches can be coerced into SVG primitives by “export” functions within their respective software.

-- 
GitHub Notification of comment by Zambonifofex
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/754#issuecomment-557756836 using your GitHub account

Received on Saturday, 23 November 2019 02:22:21 UTC