[swfmill] future of swfmill
hey all, most of you are probably using swfmill happily to produce asset libraries. Some even to do more complex stuff. Some have bugs pending in swfmill's tracker that i haven't had the time to investigate or fix. You might've noticed that i haven't been too busy with swfmill since last summer. I think it's time to let you know about my plans for swfmill: * i've started a rewrite of the core SWF-read/write functionality of swfmill- in haXe/neko. the project is (currently) called hxswf. * except for writing the core, roughly the following must be done to make the haxe-based rewrite as featureful as swfmill 0.2: * integration of libxml/libxslt into neko * xml (SAX-based) read/write functionality for the core classes * adding image and font reading/conversion * putting it all together, and tidbits here and there (for swf and svg import, if nothing else). all of these are substantial tasks - and i currently have no intention of doing them, unless someone steps forward and offers funding, because i have very little personal interest in the (otherwise widely-used) asset-generation functionality. * work on swfmill-0.2.x will continue-- from my side with occasional fixes, and probably/hopefully from steve's side, too. anyone else is invited, of course. so please do not worry that this is in some way putting an end to swfmill as you know it- if nothing else, if the current version works well for you, there is no reason it should stop doing so in the future. it just means that my activity with swfmill-0.2 will stay as low as it has been during the last half year or so - while i focus on the core rewrite, xinf, and other projects. best, -dan -- http://0xDF.com/ http://iterative.org/ ___ swfmill mailing list swfmill@osflash.org http://osflash.org/mailman/listinfo/swfmill_osflash.org
Re: [swfmill] future of swfmill
Hi Dan, all, Replies inline: most of you are probably using swfmill happily to produce asset libraries. Some even to do more complex stuff. Some have bugs pending in swfmill's tracker that i haven't had the time to investigate or fix. You might've noticed that i haven't been too busy with swfmill since last summer. I think it's time to let you know about my plans for swfmill: * i've started a rewrite of the core SWF-read/write functionality of swfmill- in haXe/neko. the project is (currently) called hxswf. Interesting. I saw you mentioned this on the xinf list. Is this code available somewhere. It might be the excuse I didn't really want to start looking at haXe (having previously written it off as YAPL). * except for writing the core, roughly the following must be done to make the haxe-based rewrite as featureful as swfmill 0.2: * integration of libxml/libxslt into neko * xml (SAX-based) read/write functionality for the core classes * adding image and font reading/conversion * putting it all together, and tidbits here and there (for swf and svg import, if nothing else). all of these are substantial tasks - and i currently have no intention of doing them, unless someone steps forward and offers funding, because i have very little personal interest in the (otherwise widely-used) asset-generation functionality. Fair enough - they are substantial tasks. * work on swfmill-0.2.x will continue-- from my side with occasional fixes, and probably/hopefully from steve's side, too. anyone else is invited, of course. so please do not worry that this is in some way putting an end to swfmill as you know it- if nothing else, if the current version works well for you, there is no reason it should stop doing so in the future. it just means that my activity with swfmill-0.2 will stay as low as it has been during the last half year or so - while i focus on the core rewrite, xinf, and other projects. This was the bit I really wanted to respond to. I'll keep working on swfmill 0.2.x so long as I have the time and people are finding it useful. I don't know whether we'll ever get to the stage of AVM2 support, but if enough people are interested then it might happen. I should qualify my statement above by saying that in I'm in the middle of another book project at the moment, and I've probably got another one lined up after that one's finished. With a full-time job and the occasional freelance project, I don't have a great deal of free time to spend on swfmill at the moment. I intend to get Flash 8 filter support wrapped up, but after that I'll only provide occasional fixes when time/desire permits. However, if a particular bug fix or feature is a priority for you and/or your company, and you're willing to fund development time, then I'm available. Cheers, Steve -- Steve Webster http://dynamicflash.com ___ swfmill mailing list swfmill@osflash.org http://osflash.org/mailman/listinfo/swfmill_osflash.org
Re: [swfmill] future of swfmill
Steve Webster [EMAIL PROTECTED] (on Tue, 27 Jun 2006 17:32:46 +0100): * i've started a rewrite of the core SWF-read/write functionality of swfmill- in haXe/neko. the project is (currently) called hxswf. Interesting. I saw you mentioned this on the xinf list. Is this code available somewhere. not yet, i'll publish on this list once it does something :) just for some internals, i decided to use a neko-C helper library to do the bitstream reading/writing- the classes for SWF Tags are haXe, though. let me know when you consider f8 support done enough-- maybe even if it's not complete we should do a proper release one of these days-- there's so many fixes and enhancements in the pre's already :) -dan -- http://0xDF.com/ http://iterative.org/ ___ swfmill mailing list swfmill@osflash.org http://osflash.org/mailman/listinfo/swfmill_osflash.org
Re: [swfmill] future of swfmill
On 6/27/06, daniel fischer [EMAIL PROTECTED] wrote: Steve Webster [EMAIL PROTECTED] (on Tue, 27 Jun 2006 17:32:46 +0100): * i've started a rewrite of the core SWF-read/write functionality of swfmill- in haXe/neko. the project is (currently) called hxswf. Interesting. I saw you mentioned this on the xinf list. Is this code available somewhere. not yet, i'll publish on this list once it does something :) just for some internals, i decided to use a neko-C helper library to do the bitstream reading/writing- the classes for SWF Tags are haXe, though. let me know when you consider f8 support done enough-- maybe even if it's not complete we should do a proper release one of these days-- there's so many fixes and enhancements in the pre's already :) Maybe I'm just missing something because I haven't tried any of the FP8 features yet, but what else would have to be supported? Frankly, it's been a long time since I ran into any limitations with swfmill, apart from the experimental SVG import. It's a great tool already, and as long as you two keep fixing the occasional bug, even if it takes a bit until you get to it, there's really nothing else I could ask for. In the long run, a haXe-based swfmill-like tool will be much more valuable, IMHO, because haXe is much more accessible for the users (read: me). Don't know about the name, though... So, is swfmill called final now? :) Thanks! Mark, will buy Dan a beer ___ swfmill mailing list swfmill@osflash.org http://osflash.org/mailman/listinfo/swfmill_osflash.org
Re: [swfmill] future of swfmill
Steve Webster [EMAIL PROTECTED] (on Tue, 27 Jun 2006 17:51:57 +0100): just for some internals, i decided to use a neko-C helper library to do the bitstream reading/writing- the classes for SWF Tags are haXe, though. That probably makes sense. Is haXe even low-level enough to allow bit manipulation et al? well, at least neko is :). it would probably work in pure haxe- but i would have to write IEEE floats and doubles by hand or something, and haxe has somewhat of a quirk with integers (they're all signed 31bit). i thought about doing a proper ANSI-C libswf, but decided against it (at least for now), for intuitive reasons :) I think once filter support is done (I've got a bug at the moment where it's writing too many / not enough bytes and I need to spend some time figuring out why) then we can do a proper release. Cool. And good luck (or whatever a writer needs) for your book. -dan -- http://0xDF.com/ http://iterative.org/ ___ swfmill mailing list swfmill@osflash.org http://osflash.org/mailman/listinfo/swfmill_osflash.org
Re: [swfmill] future of swfmill
Mark Winterhalder [EMAIL PROTECTED] (on Tue, 27 Jun 2006 18:55:04 +0200): Don't know about the name, though... eh, hxswf is just the swf-readwrite-library. if the haxe effort gets to have swfmill-like functionality, it will be swfmill-0.3 (see below). So, is swfmill called final now? :) there's no such thing as final :) seeing that swfmill performs fine in most cases, it's probably time to remove the alpha disclaimer (and replace it with the usual we'll-shoot-yer-foot-dont-complain one). so i'd call the 0.2.x branch stable- implying maybe that your swfml-ll and -simple files will keep working throughout the branch. should a haxe-based swfmill come along, it will likely be swfmill-0.3 (an odd number denoting a development/unstable version)-- and 0.2.x will stay around until 0.3 goes 0.4 (only when it matches or supercedes 0.2's functionality). If anyone should be confused by this versioning scheme: http://en.wikipedia.org/wiki/Linux_kernel#Version_numbering will buy Dan a beer sweet. -dan -- http://0xDF.com/ http://iterative.org/ ___ swfmill mailing list swfmill@osflash.org http://osflash.org/mailman/listinfo/swfmill_osflash.org
Re: [swfmill] future of swfmill
Maybe I'm just missing something because I haven't tried any of the FP8 features yet, but what else would have to be supported? Font metrics for the new text renderrer engine 5flashtype or something). Frankly, it's been a long time since I ran into any limitations with swfmill, apart from the experimental SVG import. Same here. Best regards. --- erixtekila http://blog.v-i-a.net/ ___ swfmill mailing list swfmill@osflash.org http://osflash.org/mailman/listinfo/swfmill_osflash.org
[swfmill] Named colours in SVG - a newbie writes
I apologise in advance if you guys already know this, but swfmill does not seem to likenamed colour descriptions in SVG, or at least some of them. I have tried converting svg's into swf asset libraries. Some of them - even quite simple ones - have entries in the style attribute such as fill:black. swfmill gets the shapes right but generally changes colours to something arbitrary like lime green (or maybe it does not define them at all and the player makes a substitution, anyway...). if I edit the svg by hand and change fill:black to fill:#00 it works. Initial investigation suggests this affects fill: and stroke: CSS attributes but i have not analysed the problem extensively.This is relevant because I think the latest release of inkscape (0.44) has started using named colours extensively when writing svg.Can get around my current problems with textual substitution for now. I guess the 147 named svg colours could be added to the XSLT sometime as a more reliable alternative.Rob Burbidgeps for USA readers s/colour/color/g___ swfmill mailing list swfmill@osflash.org http://osflash.org/mailman/listinfo/swfmill_osflash.org
