You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Create a supplemental transformation matrix T for the local coordinate system of the element.
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.
Post-multiply T by the rotation specified by offset-rotation.
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?
The text was updated successfully, but these errors were encountered:
This is a great section to have, but I think it's unnecessarily convoluted.
If "path" isn't already defined as the geometry of the thing specified in
offset-path
, go fix that inoffset-path
. :P Then delete this line. (Also see comment in #72 about using a more precise term.)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.
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.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?
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?
The text was updated successfully, but these errors were encountered: