Hi Ralf, > I didn't really understand what you wrote about the bounding boxes. The > SVG import calculates the bounding boxes to fit the paths (at least I > hope it does correctly).
it seems like the size of the bounding box is calculated correctly, however, the reference point isn't. Sub-groups have their origin at 0,0 on the screen, but the actual graphics wherever they were in the SVG. Ideally, they would have the reference point at the top-left corner of the visible graphics and their containing symbol placed at the correct position. I hope this makes sense. Mark On 7/7/07, Ralf Fuest <[EMAIL PROTECTED]> wrote: > Hello Mark, > I've just did a bit of research myself, but I'm not a SWF9 expert. > I was able to use a SVG file in the library with some manual > manipulation of the SWF file generated by swfmill. I've removed all the > export tags of all paths, this removed all the "ReferenceError: Error > #1065: ..." errors. I think an option to do this automatically (as you > suggested) would be a good idea. I suggest a attribute to the clip tag, > wich is used to specify whether swfmill creates symbols for all paths > (the current behavior), for the groups or only one toplevel symbol. Do > you think this is a good solution? > The other error "ReferenceError: Error #1056: Cannot create property foo > on bar" can be fixed by removing the linkage identifier (name attribute) > from the toplevel sprite's PlaceObject2 tag. I'm not sure whats the best > solution for this problem. But I think this linkage identifier could be > removed completely, because you'll normally don't have to refer to this. > I didn't really understand what you wrote about the bounding boxes. The > SVG import calculates the bounding boxes to fit the paths (at least I > hope it does correctly). > > Ralf > > > > OK, I researched this a bit, which leads me to a feature request. > > > > The problem: > > If I want to use an SVG as a library asset for SWF9, I have to create > > classes not just for the asset, but for each of it's descendants. For > > example, if the SVG consists of a group Foo that contains another > > group Bar, which itself contains a group Baz, I have to declare > > classes for each of them. Not just that, class Bar must have a > > property Baz, and Foo must have a property Bar. Plus, if it's haXe, > > all the group names must be capitalized (because haXe rightfully > > enforces capitalized class names). > > > > My idea to deal with this by rather inelegantly applying 'grep -v id' > > on my SVG file (and manually naming the main group) unfortunately made > > it invisible. The MovieClip hierarchy seems to be intact, though -- I > > can cast children of the main group to MovieClip and traverse deeper > > down the tree. It's just not visible. > > > > I guess that can be partially dealt with by writing a tool that > > creates the necessary class files with the child clips as properties, > > but it would be cool if Swfmill could, at least optionally, take care > > of the capitalization of the group IDs. Also, it would remove clutter > > in the code if it could turn generic paths (i.e., "path2345") into > > shapes instead of symbols (so that they don't require a class). A huge > > load of sugar on the top would be if it could (optionally) calculate > > the bounding rectangles and position the symbols, even if the group is > > positioned at 0,0 with the visible part being somewhere else (or does > > it even do that already? I didn't manage to display anything yet, so I > > don't know). > > > > Maybe I'm just doing something wrong, I don't know. > > > > Mark > > > _______________________________________________ > swfmill mailing list > [email protected] > http://osflash.org/mailman/listinfo/swfmill_osflash.org > _______________________________________________ swfmill mailing list [email protected] http://osflash.org/mailman/listinfo/swfmill_osflash.org
