- From: David Flanagan <david@davidflanagan.com>
- Date: Wed, 11 Aug 2010 14:42:28 -0700
Ian Hickson wrote: > On Mon, 19 Jul 2010, David Flanagan wrote: >> Even changing the argument names to neutral a,b,c,d,dx,dy would be >> better than what is there currently. > > Done. > Thanks > On Mon, 19 Jul 2010, David Flanagan wrote: >> While I'm harping on the transform() method, I'd like to point out that >> the current spec text "must multiply the current transformation matrix >> with the matrix described by..." is ambiguous because matrix >> multiplication is not commutative. Perhaps an explicit formula that >> showed the order would be clearer. >> >> Furthermore, if the descriptions for translate(), scale() and rotate() >> were to altered to describe them in terms of transform() that would >> tighten things up. > > Could you describe what interpretations of the current text would be valid > but would not be compatible with the bulk of existing implementations? I'm > not sure how to fix this exactly. (Graphics is not my area of expertise, > unfortunately. I'm happy to apply any proposed text though!) > I think that the sentence "The transformations must be performed in reverse order" is sufficient to remove the ambiguity in multiplication order. So the spec is correct (but confusing) as it stands, except that it doesn't actually say that the CTM is to be replaced with the product of the CTM and the new matrix. It just says multiply them. I suggest changing the description of transform() from: > must multiply the current transformation matrix with the matrix described by: To something like this: must set the current transformation matrix to the matrix obtained by postmultiplying the current transformation matrix with this matrix: a c e b d f 0 0 1 That is: a c e CTM = CTM * b d f 0 0 1 Changing translate(), scale() and rotate() to formally define them in terms of transform() would be simple, and the current prose descriptions of the methods could then be moved to the non-normative green box. The current descriptions suffer from the use of the word "add" near the word "matrix" when in fact a matrix multiplication is to be performed, but I don't think they can be mis-interpreted as they stands. I'd be happy to write new method descriptions if you want to tighten things up in this way, however. David
Received on Wednesday, 11 August 2010 14:42:28 UTC