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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
