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

["Evenblij, Paul" <Pa...@nl.compuware.com>]

Hi,

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

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

Do people agree that this is a bug? Are there compelling reasons for this
behaviour (e.g. performance)? Is there a reason why I should not fix this?
My code for caching images is quite heavily dependent on transformations to
get the image data to show correctly. Long attribute strings would sort of
defeat the whole caching scheme...

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?

[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

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