I've been doing a boat load of JSFL recently for this Sesame project (50,000 assets will drive anyone to JSFL). One of the things that always bothered me in JSFL though, was the inability to manipulate bitmap fills. That may not seem like a big deal, however it is *the one thing* that prevents accurate document transformation/recreation. I made a tool 'sel2Draw' a few years back for a devnet cd, where you could select an object on the stage, and it would convert it all to code. It could do everything *but* bitmap fills. So it worked ok, but if you wanted to use it for anything automated you couldn't trust it. Yes, a toy.

Completeness is really important for this current side project, so I decided to do the dirty. I was about half way through hooking up the swfParser/Generator lib (from theConverted) to get the info from an exported swf (yuck). Getting that and matching it up, even with the tools, is tricky -- and you end up with a lot of new problems. Besides, it is just ugly, and I mean that in the bad sense of the word. About half way through though, I realized there was enough info to get bitmap fills from JSFL alone! It is actually pretty straight forward in the end, not sure why I didn't get this last time. I did hook it all up to sel2Draw, and sure enough it worked : ).

By paragraph three, you really need to get to the point. The way sel2Draw gets colors, is it converts the vectors into closed rings, and then tests the inside of those rings by making a small selection. You can then call getCustomFill on the selection (not to trivialize, getting the rings and knowing where to sample is actually a fairly hard problem). So if this sample is a bitmapFill, you will get back 'red solid fill' from JSFL (bitmap fills are red underneath, as you can see when you accidentally delete a bitmap from the library). So solid red color is the flag that tells you when you need to test for a bitmap fill. All you have to do here is paste your little selection in a new document, then check that doc's library. It will either be empty (which means it was an actual red fill), or the new library will have a single bitmap, which will have the same name as the bitmap fill used in your fill! The original solid red fill will still have a matrix, and that is the bmpFill matrix.

To recreate that fill, place the bitmap of the same name somewhere on to a blank peice of stage. Then apply the matrix to it, and break it apart (in that order). Sample this the same way (selection, getCustomFill), delete this temp object, and then fill your real object with the current fill (make sure the fill is locked). And that is all there is to do : ).

Here is some temp code I was using, it assumes a single unicolor selection. Obviously you could make it more efficient, eg, I use a single scratch doc that keeps getting cleaned out for this for the whole parse, etc... In any case, this is the jist...

    else if(foundFill.style == "solid")
    {   
        var colString = foundFill.color.substring(1,8);
        foundString = "[0x" + colString + "]";
        var bmpFill = "";
        if(colString.toLowerCase() == "ff0000")
        {
            // might be bitmap fill
            curDoc.clipCopy();
            var testDoc = fl.createDocument();
            testDoc.clipPaste();
            
            for (var i = 0; i < testDoc.library.items.length; i++) 
            {
                var itm = testDoc.library.items[i];
                if (itm.itemType == "bitmap") 
                {           
                    bmpFill = itm.name;
                    break;
                }
            }
            fl.closeDocument(testDoc, false);
            trace("bmpFill: " + bmpFill);
        }
    }