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

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

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

EP> While working on a solution which should make it possible to cache
EP> raster image data (yes, I have a working version!;) I noticed the
EP> following:

EP> org.apache.batik.ext.awt.g2d.TransformStackElement has a method
EP> "concatenate()" which essentially reduces 2 affine transforms of
EP> the same type to 1. However, only translations, rotations and
EP> scales are supported.  General transformations represented in
EP> matrix form cannot be concatenated.  This may result in SVG
EP> transform attribute strings of epic length...

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)...


---------------------------------------------------------------------
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?

[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