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

[Vincent Hardy <vi...@sun.com>]

Thomas E Deweese wrote:
> 
> ....
> EP> Do people agree that this is a bug? Are there compelling reasons
> EP> for this behaviour (e.g. performance)? Is there a reason why I
> EP> should not fix this?  My code for caching images is quite heavily
> EP> dependent on transformations to get the image data to show
> EP> correctly. Long attribute strings would sort of defeat the whole
> EP> caching scheme...
> 
>     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 
(and sometimes more concise, because scale(2,3) is shorter than
the matrix equivalent). When I wrote the TransformStack, my goal
was to find a solution that would produce readable SVG and would
be concise enough in many cases...

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.

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