Show need for "segment-completing closepath" with curves/arcs

[tshinnic]

Summary:

• WG discussions about arc/curve end point and closepath
• a need for method to say the arc/curve end point is initial point
• insiders can 'visualize' need but how to show everybody else?
• a spotty overview of current browser displays
• link to demo of linejoin problems Codepen
• any better demos suggested?
• (markers should be done next)

.
There were SVG2 WG discussions regarding the revealed inability for SVG1.1 to express how a path that ends with a curve or arc segment could be closed 'nicely'. That is, how do you close a path where the final segment is a curve or arc without introducing an extra straight line path segment with the closing 'Z'?

In the WG discussions those involved naturally understood the implications when "linejoin behavior" and "marker behavior" were both mentioned as affected by insertion of extra line segments. They could easily mentally model the gross visible defects possible.

The WG hence resolved to modify the SVG path grammar and interpretation to add a means for specifying that a curve or arc is in fact the final segment in a closed path. At least for working purposes the means to signal this was called a "segment-completing close path"

For explanation to the rest of us it would be very good to have some explicit pictures of the distortions seen when lacking this feature. This should show the utility of the change to users and implementers.

There is difficulty in coming up with an easily recognized illustration of the distortions from SVG 1.1 closepath with curves/arcs. Another difficulty is that browsers differ in how well they "cover up" the previous gap in the SVG spec.

In particular, Edge does very well at recognizing when a curve/arc finishes so very 'near' to the initial point, that the following closepath should not create an extra segment. Edge patches up the display so that nothing ugly is seen. However the good intentions will fail if the initial / end point differences are greater than some tolerance factor, when the unfortunate behaviors break through into visibility.

And note that when curves/arcs are generated by algorithm that computation errors might increase to visibility. How can a final relative curve/arc indicate that it ends at the initial point? Artifacts have seen before where one browser used single-precision math internally, which over several segments caused visible defects. So the problem can also be said to be, how can a curve/arc directly specify its logical end point is the initial point?

.
I think the WG decision has merit, but it would be nice to make it obvious through examples.

.
I have been playing with linejoin to demonstrate problems. It is difficult because Edge tries hard to out-psych problems, and Chrome just acts weird sometimes. Only FireFox is the perfect example (!) of what should not happen.

I am throwing these examples out here to see if someone can come up with better and more succinct visualizations of closepath interfering with final curves/arcs.

To show how clumsy I am at this, here is

an ideal vertex (at center) where two intermediate arcs meet,

then a broken vertex where an initial and a final arc 'meet',

then zoomed in on that broken vertex,
showing that the closepath between the arcs has inserted a straight horizontal line segment.

.
More examples are seen in the Codepen

[boggydigital]

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone