Jean Abou Samra <[email protected]> writes: > Le 20/09/2021 à 23:55, David Kastrup a écrit : >> Jean Abou Samra <[email protected]> writes: >> >>> Le 20/09/2021 à 23:31, David Kastrup a écrit : >>>> Jean Abou Samra <[email protected]> writes: >>>> >>>>> Thoughts? One would have to look at the most typical use cases >>>>> to decide on an interface. >>>> Anything wrong with using a ly:transform? type? It's straightforward to >>>> create and manipulate. >>> I had already forgotten about those. Given sufficient >>> documentation, it would probably work well. >> I find in the IR: >> >> -- Function: ly:make-transform xx yx xy yy x0 y0 >> Create a transform. Without options, it is an identity transform. >> Given four arguments XX, YX, XY, and YY, it is a linear transform, >> given six arguments (with X0 and Y0 last), it is an affine >> transform. Transforms can be called as functions on other >> transforms (concatening them) or on points given either as complex >> number or real number pair. See also ‘ly:make-rotation’, >> ‘ly:make-scaling’, and ‘ly:make-translation’. >> >> -- Function: ly:transform? x >> Is X a ‘Transform’ object? >> >> -- Function: ly:transform->list transform >> Convert a transform matrix to a list of six values. Values are XX, >> YX, XY, YY, X0, Y0. >> >> -- Function: ly:make-translation x y >> Make a transform translating by X and Y. If only X is given, it >> can also be a complex number or a pair of numbers indicating the >> offset to use. >> >> -- Function: ly:make-rotation angle center >> Make a transform rotating by ANGLE in degrees. If CENTER is given >> as a pair of coordinates, it is the center of the rotation, >> otherwise the rotation is around (0 . 0). >> >> -- Function: ly:make-scaling scale scaley >> Create a scaling transform from argument SCALE and optionally >> SCALEY. When both arguments are given, they must be real and give >> the scale in X and Y direction. If only SCALE is given, it may >> also be complex to indicate a scaled rotation in the manner of >> complex number rotations, or a pair of reals for specifying >> different scales in X and Y direction like with the first calling >> convention. > > > 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. -- David Kastrup
