You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by "Evenblij, Paul" <Pa...@nl.compuware.com> on 2001/09/04 15:26:24 UTC
RE: Reduction of 2 concatenated matrix-based affine transforms no
t supported in svggen?
Vincent Hardy wrote:
> Thomas E Deweese wrote:
> >
> > [...]
> > I'm guessing it is done so people can read the result. I can
> > make a lot more sense out of:
> >
> > transform="rotate(45), scale(0.5)"
> >
> > As opposed to:
> > transform="matrix(0.35, 0.35, -0.35, 0.35, 0, 0)"
> >
> > (or what ever the correct result is...)
> >
> > This might be something that could be control by a hint, or the
> > like. Perhaps the TransformStack could re-decompose a matrix
> > transform into a scale, rotate, translate (when shear is not
> > involved)...
>
> Thomas is right, this was done so that the svg is more readable
> [...]
> However, I agree that if you keep modifying the transform you
> end up with a long transform string which no longer makes sense...
> In addition to what Thomas suggests, you could also put a limit on
> the number of entries in the transform stack: beyond that limit,
> the stack is collapsed and the matrix notation could be used...
>
> Vincent.
Okay. Thank you for that clarification and suggestion. The problem currently
is that I get long transform strings in *matrix* notation, e.g.:
transform="matrix(0.35, 0.35, -0.35, 0.35, 0, 0)
matrix(0.34222222222235, 3.35, 345, 345, 0, 0) matrix(123, 13.5, 0.1,
0.21232023123, 45, 43) matrix(0.132496565, 0.2434954850345, 5675, 5757, 0.1,
0.1) matrix(354.345345, 123.45678, 354.3544, 354.23243, 0, 0)"
because there is no code to collapse matrices. This is even less readable
than the one Thomas offered. My first approach would be to add matrix
multiplication to TransformStackElement.concatenate(), so as to get rid of
the pathological cases like above. Then later stuff could be added to
decompose where possible and useful.
Another approach would be to avoid stacks of matrices like that being
generated in the first place, but I don't know if this can be done well. In
my image caching code at least it would mean some loss of generality.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: Reduction of 2 concatenated matrix-based affine transforms not
supported in svggen?
Posted by Vincent Hardy <vi...@sun.com>.
Paul,
"Evenblij, Paul" wrote:
>
> Vincent Hardy wrote:
> ...
> >
> > Thomas is right, this was done so that the svg is more readable
> > [...]
> > However, I agree that if you keep modifying the transform you
> > end up with a long transform string which no longer makes sense...
> > In addition to what Thomas suggests, you could also put a limit on
> > the number of entries in the transform stack: beyond that limit,
> > the stack is collapsed and the matrix notation could be used...
> >
> > Vincent.
>
> Okay. Thank you for that clarification and suggestion. The problem currently
> is that I get long transform strings in *matrix* notation, e.g.:
>
> transform="matrix(0.35, 0.35, -0.35, 0.35, 0, 0)
> matrix(0.34222222222235, 3.35, 345, 345, 0, 0) matrix(123, 13.5, 0.1,
> 0.21232023123, 45, 43) matrix(0.132496565, 0.2434954850345, 5675, 5757, 0.1,
> 0.1) matrix(354.345345, 123.45678, 354.3544, 354.23243, 0, 0)"
>
Understood.
> because there is no code to collapse matrices. This is even less readable
> than the one Thomas offered. My first approach would be to add matrix
> multiplication to TransformStackElement.concatenate(), so as to get rid of
> the pathological cases like above.
Right: I think this is the best idea as I would agree it is a bug if
to successive matrix() TransformStackElement do not concatenate.
> Then later stuff could be added to
> decompose where possible and useful.
I agree again: other optimizations could be done later if needed.
>
> Another approach would be to avoid stacks of matrices like that being
> generated in the first place, but I don't know if this can be done well.
Well, not very easily. The is a setTransform method in Graphics2D and
not using matrices for arbitrary transforms would mean decomposing
them which is not necessary optimal...
In summary, I think I would go with your suggesting of fixing the
collapse method and keep at that.
Thanks!
Vincent.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
RE: Reduction of 2 concatenated matrix-based affine transforms no t
supported in svggen?
Posted by 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