Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[motion] Unobfuscating calculating the path transform #75

Closed
fantasai opened this issue Nov 5, 2016 · 1 comment
Closed

[motion] Unobfuscating calculating the path transform #75

fantasai opened this issue Nov 5, 2016 · 1 comment
Labels

Comments

@fantasai
Copy link
Contributor

fantasai commented Nov 5, 2016

Calculating the path transform

This is a great section to have, but I think it's unnecessarily convoluted.

Let path be the geometry of the closed line segment, specified basic shape, path or SVG shape element reference.

If "path" isn't already defined as the geometry of the thing specified in offset-path, go fix that in offset-path. :P Then delete this line. (Also see comment in #72 about using a more precise term.)

Let distance be the computed value of offset-distance.

I think you mean the "used" offset distance here. Also, you already defined this concept in the previous section (discussed in #74). So delete this line.

If path is a valid path:

Is it ever not a valid path? If it's not a valid path, do something about that in the offset-path section. By the time we get here, the thing we're calling a "path" (or "offset path" or whatever per #72) should be valid.

Determine the computed distance by invoking the process for Calculating the computed distance along a path on path and distance.

Yeah, so we did this thing and gave it a name, right? Delete this line and just use that term.

We make terms so that they can be referenced, so let's reference them! No need to redefine things for the sake of looking "formal". Being well-defined isn't about looks or repetition.


As for the rest of it, it's maybe my unfamiliarity with the technicalities of transformation matrixes, but how about rewriting it as something like this?

Calculating the path transform

  1. Create a supplemental transformation matrix T for the local coordinate system of the element.
  2. Let position be the point at the "used offset distance" (or whatever) along the "offset path" (or whatever). Find the translation of the box such that its anchor point is placed at position, and apply that to T.
  3. Post-multiply T by the rotation specified by offset-rotation.
  4. Post-multiply T to the local coordinate system of the element.

I don't know what post-multiplying is, so you might need to fix up some prepositions here... but I think this is a bit more readable?

@jihyerish
Copy link

Thanks for your comments : )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants