- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Sat, 05 Nov 2016 04:05:45 +0000
- To: public-fxtf-archive@w3.org
fantasai has just created a new issue for https://github.com/w3c/fxtf-drafts: == [motion] Unobfuscating calculating the path transform == > 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 https://github.com/w3c/fxtf-drafts/issues/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 https://github.com/w3c/fxtf-drafts/issues/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 https://github.com/w3c/fxtf-drafts/issues/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 <var>position</var> 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 <var>position</var>, 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? Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/75 using your GitHub account
Received on Saturday, 5 November 2016 04:05:51 UTC