Last night Betsy Weber, TechSmith’s Chief Evangelist, dragged me to MI UPA meeting which I had mixed feelings about going into–I tend to battle some usability folks who seem averse to aesthetics and are always shoving “Windows standards” down my throat. However, I walked away from the event completely inpired. Up until last night I had never heard of Tom Brinck, but after listening to him expound on usability and user-experience–I have to say the man totally rocks! Tom totally gets it. He knows what web / interface design is all about and his presentation was easily one of the best I’ve ever seen at a user group meeting (hell it was better than most of the sessions you see at conferences).
Perhaps the most fascinating part of the evening was his discussion of Wabi-sabi influenced user-experience design. The philosophy is one of elegance through simplicity and utility, but aknowledges there is inherent beauty in such a design. One of his slides was diagram created by Peter Boersma which outlines the relationship between Wabi-sabi and user-experience design which provides a pretty good overview of topic.
Anyways, this was interesting enough that I thought I’d throw it out into the blogosphere for others to nibble on.
After discovering how to compress / decompress swf files via the Java Deflater / Inflater api, I’ve abandoned the RandomAccessFile method of reading the swf and moved to just using a FileInputStream to create a byte array which can then be examined byte by byte, or, in some cases, bit by bit. The end result is a lightweight Java solution for parsing the header of any swf irregardless of whether the swf is compressed or uncompressed.
Another significant change has been reading the swf size from the header rather than just looking at the number of bytes in the file. This is critical when reading a compressed swf since the header contains information about the number of bytes the file will consume when uncompressed.
As with the previous version you are able extract the following information from the header:
- file signature ( “FWS” if uncompressed or “CWS” if compressed)
- size (in bytes)
- width (getWidth converts the twips to pixels for you automatically)
- height( again twips to pixel conversion is taken care of)
- frame rate
- frame count
I’m again providing both a jar an java source files:
I’m really interested in tackling reading / writing metadata in the swf format, so if anyone has ideas or suggestions give me a yell.
I found a bug which effects reading the frame rate and frame count. Because the swf width and height are stored in a “packed” format (the number of bytes needed to store the dimensions varies) I couldn’t use an arbitrary count to read frame rate and frame count. Instead the parseHeader method now stores an iterator that keeps track of the next byte that needs to be read. The jar and source files available above have been updated accordingly.
Several users noted a bug where large dimension swf files (width & height) were failing to be read. Anson, noted that the using the >>> operator to deal with right shifts does not work as defined in the Java documentation. Instead, every time a right shift is needed we to mask and do a standard right shift – (someByte & 0xff) >> 3. The jar and source files have been updated in the links above.
This example reads a swf file into a byte array and decompresses / inflates all of the bytes of the swf except for the the first 8 bytes which are always uncompressed. As most swf files have zlib compression applied, file decompression is necessary if you wish to fully parse the swf. As with the previous post on swf compression, this is a very raw example–no file signature or compression checking is performed before attempting to inflate the file.
The title pretty much says it all–this code sample illustrates how to compress a swf file using the Java Deflater class to perform the zlib compression on all the bytes of the swf except for the first 8 bytes which are always uncompressed. This class isn’t intelligent in the sense that it doesn’t check to see if you actually have a valid swf file signature, or check to see that the file is actually uncompressed. So basically you have swf compression in its rawest form.