W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > November 2016

[fxtf-drafts] [motion] Unobfuscating calculating the path transform

From: fantasai via GitHub <sysbot+gh@w3.org>
Date: Sat, 05 Nov 2016 04:05:45 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issues.opened-187475333-1478318743-sysbot+gh@w3.org>
fantasai has just created a new issue for 

== [motion] Unobfuscating calculating the path transform ==
> Calculating the path transform

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

> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 November 2018 00:45:56 UTC