- From: Boris Dalstein via GitHub <sysbot+gh@w3.org>
- Date: Sat, 23 Nov 2019 18:49:49 +0000
- To: public-svg-issues@w3.org
I'd say that if your use of SVG is strictly as an export format for static images (that is, neither for editing, or animating, or allowing user interactivity), then I agree that adding topological semantics isn't that useful, and in fact that the proposition of @Doktorchen seems good enough. However, in this case, there isn't either any need for more involved path shapes at all. Any shape can be accurately depicted using filled paths. The reason for stroked paths, and other high-level primitives like rect, circle, etc., is three-folds: 1. To make them easier to author by hand. 2. To add more semantics which is useful for editing / animating / enabling user interactivity. 3. To potentially save on file size. Adding n-way joins and shared edges à-la Figma or VGC is definitely a huge step forwards in all these three points, and you seem to be potentially interested by the first point :-) --- Regarding "proper stroke linejoin", I agree that for static images, and if all your incident edges have the same width and the same color, you can simply have the two "exterior" edges be one joined path as a workaround:  However, it doesn't work if you have different colors and/or widths:  Or if you have semi-transparent edges:  And obviously it doesn't work if you animate/edit which of the two edges are the "exterior" ones (note that the three edges do share the same exact end position):  All of these could be elegantly solved if the spec allowed paths to share endpoints, and add explicit rules on how they should be rendered (which is a hard problem, I have to admit). I have this figure in my PhD thesis:  --- Anyway, the real power and motivation behind adding topological information is indeed not to be able to represent n-way line joins, but to be able to represent shared path-data between different paths. It does solve all the problems you are presenting here, and more. I forgot to mention another attempt at standardizing this type of things into SVG: superpaths https://hal.archives-ouvertes.fr/hal-01793944/file/SuperPathSVGOpen.pdf https://github.com/moissinac/SuperPath -- GitHub Notification of comment by dalboris Please view or discuss this issue at https://github.com/w3c/svgwg/issues/754#issuecomment-557823137 using your GitHub account
Received on Saturday, 23 November 2019 18:49:51 UTC