RE: Reduction of 2 concatenated matrix-based affine transforms no t supported in svggen?

[Thomas E Deweese <th...@kodak.com>]

>>>>> "EP" == Evenblij, Paul <Pa...@nl.compuware.com> writes:

EP> Okay. Thank you for that clarification and suggestion. The problem
EP> currently is that I get long transform strings in *matrix*
EP> notation, e.g.:

EP> because there is no code to collapse matrices. This is even less
EP> readable than the one Thomas offered. My first approach would be
EP> to add matrix multiplication to
EP> TransformStackElement.concatenate(), so as to get rid of the
EP> pathological cases like above. Then later stuff could be added to
EP> decompose where possible and useful.

    I would agree that multiplying the matrixes when matrix form is
use is always the right thing to do. I would probably do it even if
the second matrix is decomposable, since I would rather have one
incomprehensible matrix than an incomprehensible matrix followed by a
comprehensible matrix, since I still would have no idea what it going
on :).

    BTW I just wanted to mention that java.awt.geom.AffineTransform
already has 'concatenate(AffineTransform at)' implemented.  I only
mention it because it sounded like you were going to do your own
matrix multiply code.

EP> Another approach would be to avoid stacks of matrices like that
EP> being generated in the first place, but I don't know if this can
EP> be done well. In my image caching code at least it would mean some
EP> loss of generality.

    I don't think this is something that should be strongly pursued.
Generate transforms as convenient, let the TransformStack worry about
cleaning them up for presentation.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org