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
