Relative or Absolute Horizontal and Vertical Lineto (H,h,V,v) --to--> Absolute Lineto(L)
Relative or Absolute Smooth CurvetoCubic (S,s) --to--> Absolute CurvetoCubic (C)
Absolute or Relative CurvetoQuadratic (Q,q,T,t) --to--> Absolute sequence of Lineto segments (L)+
Are you sure about this? I would naturally promote the
quadratic to a cubic by adding a duplicate control point, this
avoids loss of precision but would seem to comply with the subset
of segments requirement.
I have made some tests trying to promote a quadratic to a cubic, by adding a duplicate control point. The resulting curve is different, consider the following two elements, they should be identical, if we could promote simply by adding a control point, but they are not:
Quadratic curve:
<path d="M200,300 Q400,50 600,300 T1000,300" fill="none" stroke="red" stroke-width="5" />
Cubic curve:
<path d="M200,300 C400,50 400,50 600,300 S800,550 1000,300" fill="none" stroke="red" stroke-width="5" />
Absolute or Relative Arc (A,a) --to--> Absolute sequence of Lineto segments (L)+
I notice the example in the spec text but I wonder if this
was really thought through, once again the _much_ more common
thing would be to replace the arc with cubic curves (one per
quadrant of the ellipse).
As with the above example, I guess there is a whole complex mathematical problem behind this. We should take into account that there are other graphical formats (such as WMF) that usually flatten complex paths into segments, so i can assume the normalized approach is taken from this. But will look into options for transforming Arcs and Quadratic curves into Cubic without modifying the shape path.
The spec states:
"Modifications to normalizedPathSegList might cause entries in pathSegList to be broken into a set of normalized path segments."
So to my understanding, we need to track if the pathSegList resulting from a normalizedPathSegList call is modified, then the standard pathSegList will be replaced by the normalized one, with the changes. But I am also at a loss in the interpretation, since the spec also states that *animatedNormalizedPathSegList *is a readOnly property, so the option of changing values shoudl not be allowed.
You need to be careful when a property is read only it means you
can't assign something to it but it does not mean that the object
returned is read only. So you can't change the actual PathSegList
but you can completely replace the path seg list's contents
(using replaceItem, etc).
Thanks for the insight, exactly what i had feared.
The Arc is simple you simply need to make the destination point
an absolute point rather than a relative one. There is no way to
normalize the radii or the arc flags (or they are already normalized).
/I understand from the spec that the ARC should be normalized into a Flattened Curve, i.e. a series of Lineto (L) that approximate the arc.
/Also, arising from this, one item that is unclear is where and how to define the flatness threshold for normalizing, i.e. how accurate the conversion of the curve to lines is. This is usually a double value that indicates the distance allowed from the tangent to the curve until you need a next point. The spec has no clear reference to this item.
Yes, without a flattening parameter it is impossible to do this
properly (and even with it, the result is ugly). It would be much
better to use cubic curves (still not perfect but much better).
The result may be ugly, but usually that is what you expect when flattening a curve. Java 2D flatteningPathIterator only returns movteto and lineto segments. I think that the SVG spec took one little step ahead allowing cubic curveto elements.
