Re: Reduction of 2 concatenated matrix-based affine transforms not supported in svggen?

[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