This problem occurs when you define g or path elements that are not at the 
origin. According to the W3C SVG specification, these element's transformations 
need to be included in all possible references (i.e. use elements). However, in 
SWF, you cannot specify transformations in the definition of an element, only 
in the references. That's why we need the wrappers.

I was accessing the MovieClips with ActionScript too, that's why I wanted the 
structure to stay intact. However, I also care much about the position. As a 
workaround, I built in this conditional branch:

                
                        
                        
                                
                                        
                                        
                                        
                                
                        
                

If the defining element is at (0,0), then the wrapper is omitted, and both 
structure and position stay intact. Sadly, Inkscape doesn't support an asset 
library where you can store and browse your definitions, like in the Flash IDE. 
Instead, to see them all, you have to spread them out, so it's hard to keep 
them all at the origin.

An additional improvement would be to check if there actually are any 
references. Often, this is not the case in SVG documents. The wrapper could 
then be safely omitted as well.


The question is, who (if anyone) is actually using the SVG import? If graphics 
artists use it to import complete SVG graphics to be used as a whole, then 
position is everything, and structure doesn't matter much. And my impression 
was that Inkscape is geared more towards creating static images...


Your idea of an import flag is probably useful, for the wrapping as well as for 
some other aspects.

The best solution for our wrapper problem was suggested by Daniel: instead of 
wrapping the referenced elements, the 2 transforms could be combined into one, 
keeping both structure and position intact, thus eliminating the need for 
wrappers. The parsing and multiplication of matrices might be too much for 
XSLT, that's why we would need a C function.

I am currently concentrating on Batik programming, but if you would like to try 
and implement such a function, I'll be glad to help.

Cheers,
Gerrit


> Date: Fri, 15 Feb 2008 19:57:24 +0200
> From: [EMAIL PROTECTED]
> To: [email protected]
> Subject: [swfmill] Group transform attribute
>
> Hi!
>
> Attached patch removes wrapping of groups with transform attribute,
> and applies that transform to inner elements instead. It's very very
> useful if you need to access elements from actionscript.
>
> Will this sort of patch (may be not exacly this) be accepted for trunk?
>
> Probably if I care of structure of movie more than positions, somebody
> will care more about positions of movieclips (I feel that it can be not the
> same as in svg). So may be this behavior can be turned on by some
> attribute, e.g.:
> 
>
> Any thoughts?
> --
> Paul




_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_______________________________________________
swfmill mailing list
[email protected]
http://osflash.org/mailman/listinfo/swfmill_osflash.org

Reply via email to