Sure, I didn't mean that transforms weren't well-documented.
I just suggest a paragraph of NR documentation, possibly linking
back to the IR, simply because the kind of technical language
we use in IR isn't obvious to understand for most users I would
guess (linear transform? complex number? number pair? etc.).
But that's a programming tool. There is not much of a point in the NR.
And even the level of the EG does not seem to make it much of a good fit
there.
I think here we lost sight of the starting point of the discussion.
We noticed that the documentation for Grob.rotation is wrong, and I
asked whether it would make sense to provide both the current behaviour
and the behaviour claimed by the documentation. And, if I understood
correctly, Jean pointed out that in order to decide that, one would have
to look at typical use cases to see which ways of representing a grob
rotation might actually be needed.
I think it may well be that the current Grob.rotation behaviour is the
ideal solution, and that it suffices to make the documentation match the
implementation.
But if there are use cases that are more naturally served with another
representation for rotation/translation, by definition the NR would be
the place to explain the corresponding (and to be devised) interface.
Lukas
