Repository navigation
[motion-1] "equivalent path" mismatches between SVG and Motion #506
Description
Both SVG and Motion define equivalent paths for an essentially identical set of shapes. For rectangles and polygons, their definitions are identical, but for circles/ellipses they're not - SVG defines that a circle's equivalent path starts at its rightmost point (cx + rx, cy), while Motion defines that it starts at its topmost point (cx, cy - ry). They at least both agree that the path continues clockwise.
Should we align these definitions? I'm inclined to take SVG's definition just because it has earlier claim, and it seems more likely to break something if we changed SVG.
Edit: I was gonna add a comment about polygons actually being different too wrt initial direction, if you start the polygon with several identical points, but actually SVG2 has some pretty good text defining the direction of a path, and it matches up with what Motion has defined, just in a more generic fashion.
Activity
[-][motion-1] "equivalent path" mismatch for circles between SVG and Motion[/-][+][motion-1] "equivalent path" mismatches between SVG and Motion[/+]tabatkins commentedon Mar 7, 2023
After doing some more archaeology, it seems clear that only path() was actually desired for offset-path; the rest of the basic-shapes came in because we want to consistently handle all the path-ish things the same way for anything that takes any of them.
So I'm going to assume, absent any data, that there's no real usage to worry about here, and I can go ahead and change the equivalent path to match SVG.
[motion-1] Change the equivalent path of a circle()/ellipse() to matc…