- From: Boris Dalstein via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Dec 2019 01:42:32 +0000
- To: public-svg-issues@w3.org
> For rectangles that do have curved corners, would you also then recommend sticking with the segment-completing closepaths to avoid repeating the start vertex as a final mid?
Yes.
For rounded rectangles, we have the options B1, B2, C1, C2, which are the same as the non-rounded example above, except obviously that we replace `A 0 0` to `A rx ry` and offset vertex positions by rx/ry as appropriate.
My vote would be:
- For non-rounded rects: A1
- For rounded rects: B1 or C1
But what matters most is consistency.
If we decide on A2 for non-rounded rects as per @BigBadaboom vote, then we should use B2 or C2 for rounded rects. I don't have any preference between B2 and C2, so I'd vote for B2 if this is already implemented by some UAs, as it indeed affects stroke dashing.
If we decide on A1 for non-rounded rects, then we should use B1 or C1 for rounded rects. I don't have any preference between B1 and C1, so I'd vote for B1 since it provides the same stroke dashing behavior as the already implemented B2. However, B1 is only possible if segment-completing arcs make it to the standard, so obviously I'd vote for C1 instead if they don't make it to the standard.
> I don't have the same aversion to zero-length closes (Z) that some others seem to. My instinct is that the "equivalent path" should describe the whole perimeter of the shape using normal segment commands, and not rely on the pseudo-line-like behaviour that Z gives you.
Unfortunately, your instinct goes against the [very first example](https://svgwg.org/svg2-draft/paths.html#PathDataGeneralInformation) of path provided in the standard, and many other examples in the standard:
```
<path d="M 100 100 L 300 100 L 200 300 z"
fill="red" stroke="blue" stroke-width="3" />
```
Regardless of what we decide, I favor consistency above all else. If we choose A2, then I would be a strong advocate of rewriting all examples in the standard to ensure that closed subpaths are explicitly closed with a normal segment command instead of relying on the lineto behavior of Z. And I would also advocate to add a note in the standard saying that explicit closing is recommended before using Z, and that minifiers and SVG editors shouldn't trim those "redundant" lineto, since they affect markers.
For example, as I mentioned above, Inkscape automatically converts `M 0,0 H 1 V 1 H 0 V 0 z` to `M 0,0 H 1 V 1 H 0 z`. So if a rect was rendered with 4 marker-mids (what you'd get with A2), then after a "convert object to path", you'd lose a marker after the automatic simplification/minification. You could argue that it's a bug of Inkscape, but I'd argue instead that the wording of the standard strongly suggests that authors SHOULD in fact rely on the lineto behaviour of Z and not use redundant lineto, so it makes sense for editors to behave like this.
In fact, the standard makes this interpretation quite clear with how markers are defined for [zero-length path segments](https://svgwg.org/svg2-draft/paths.html#ZeroLengthSegments):
> If markers are specified, then a marker is drawn on every applicable vertex, even if the given vertex is the end point of a zero-length path segment
I read this as: "If you use zero-length path segments, you get duplicated markers, so you'd better avoid them, therefore prefer relying on the lineto behavior of Z"
This is especially important when you have several closed subpaths as part of the same path. Without using zero-lengths segments, things are already pretty bad due to the awful definition of markers, e.g.:
```M 0,0 V 30 H 50 V 0 Z M 10,10 V 20 H 20 V 10 Z M 30,10 V 20 H 40 V 10 Z```
But things get even **worse** if you explicitly close the subpaths before using Z:
```M 0,0 V 30 H 50 V 0 H 0 Z M 10,10 V 20 H 20 V 10 H 10 Z M 30,10 V 20 H 40 V 10 H 30 Z```
After having implemented countless of topological data structures in my life, my experience is that using zero-length edges / path segments when they can be avoided is always a mistake, and invariably leads to problems such as those above. A rectangle is made of four edges, not five, and trying to make it work with five will bite us in ways we can't forecast. Here it already bites us with markers, but later it will bite us in ways we don't expect with some future SVG extensions, notably more complex stroking methods.
--
GitHub Notification of comment by dalboris
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/753#issuecomment-561436594 using your GitHub account
Received on Wednesday, 4 December 2019 01:42:34 UTC