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
