Re: "liveness" of SVGMatrix

On Mon, 30 Jun 2008 10:53:25 +0200, Robert O'Callahan  
<robert@ocallahan.org> wrote:

> On Mon, Jun 30, 2008 at 6:14 PM, Anthony Grasso <
> anthony.grasso@cisra.canon.com.au> wrote:
>
>> There was an errata [1] about live values for SVG Full 1.1. Please check
>> the link. I'm not sure if the link completely answer your question  
>> though.
>>
>
> Thanks, that's helpful. However, the erratum does not indicate whether,
> after passing a matrix to "setMatrix", further changes to that matrix  
> affect
> the transform. I.e. does that object become the object returned by the
> 'matrix' attribute? I'm guessing the answer is "no" but it should be
> clarified.

What are the use-cases of having SVGTransform::setMatrix adopt the  
passed-in matrix?

IMHO it seems a bit weird to let it be live in this scenario, especially  
given that there are methods for setting translation, rotation etc on the  
SVGTransform interface. These would then affect the passed-in matrix too.

Another way to get the liveness:
tfm.setMatrix(mtx); // setting values of the tfm.matrix from mtx
mtx = tfm.matrix; // mtx is now live

Another question then is if the createSVGTransformFromMatrix method (on  
SVGSVGElement and SVGTransformList) also behaves the same. My testing for  
createSVGTransformFromMatrix so far concludes that all viewers treat the  
passed-in matrix as disconnected from the created SVGTransform (i.e. it's  
not live).

> Also, I don't understand the entry for "consolidate":
>> The returned item is the item itself and not a copy. Any changes made to
> the item are immediately reflected in the list.
> I don't think this is right. For lists with more than one matrix, this
> doesn't seem to make any sense.

Agreed. How about:
"If the list contains more than one item, then the consolidated matrix is  
written to the first item in the list while the other items are removed  
 from the list. The returned item is the first item in the list, and is the  
item itself and not a copy. Any changes made to the item are immediately  
reflected in the list."

This means that consolidate is basically a no-op for the one-item case,  
and that it becomes a consolidate-to-first-item for the multiple-items  
case.

> By the way, it would be helpful if there was a revised SVG 1.1 document  
> that
> included these errata, or at least links to them in the right places.

Yes, folding the errata items into a 1.1 second-edition spec is the plan  
going forward. This will be done in publicly readable cvs space[1].

Cheers
/Erik

[1] http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_edee

Received on Monday, 30 June 2008 12:55:56 UTC