Alright, well I've reached a point now in the implementation of the JHeidt.Utilities.Web.CssSpriteGen library where I feel comfortable not only sharing my implementation details, but hopefully some starter code to get down to the idea of the design behind it. If you haven't been following my posts on the subject, SpriteGen is an extensible library of which the goal is to take a series of images from a given input source and generate a packed raster representation of those images along with the requisite CSS rules and XHTML examples to showcase them, for your use however you please.
There currently exist a few services for creating CSS sprites, but the whole goal of CSS sprites is to allow for quicker loading of images/styles on the client side, by cutting down on request calls / upstream network bandwidth. So here is the first unequal size inputs packed image example and result, showing how I minimize the image output size by using bin packing techniques:
These images were taken, (without express written consent, but in the hopes of promoting them) from http://microformats.org/wiki/buttons. Please learn about microformats and help spread the word as well about helping make the web a contextual, and data rich environment.
Well - Here are the source images.
Note the varying height and width:
Source Image Zip: Source Images.zip
The total area for these combined input images is 89442 pixels. A perfect packing of these images (which is quite probably not possible for these inputs) would yield an image of that area.
Below we get the image that was created by SpriteGen. The ImageLoader for this case was the DirectoryImageLoader, with the default options. Image loaders provide a set of base image searching, preparation, and validation functions, and there are more options and specifics for the base and custom image loaders.
The DirectoryLoader has options for max input file size, max directory iteration file processor count, cutoff at combined total input area, max binary result size, file mask, and even more - the reason for these configurable settings was the expectation that people could use the spritegen online, perhaps forgetting to shrink an image, or upload an invalid zip file, or just downright abuse. It's important to note that I've created 3 ImageLoaders for SpriteGen so far, but the fully functional ones right now are the DirectoryLoader and the ZipFileLoader.
I can see creating a UrlScrapeLoader that could parse images from a remote web site and it's css to generate the packed images and CSS for that site as just a dead-lazy gimmegimme sprites hookup, but that's further down the road ;). Also, additions that I think would be useful would be the ability to generate output images grouped by input type, or to detect non-alpha & per-pixel alpha images and group them in with gif/JPEG raster groups as required, again to save bandwidth, so these will be looked at.
So - without further ado, here is the pack image result (output: PNG/full alpha - this can be adjusted or even broken down to separate outputs from a set of input images) This output doesn't showcase the SmartBackGround functions ability to determine repeated/repeatable background images, such as vertically aligned 1px wide, 2px+ high images as repeat-x backgrounds and vice versa for repeat-y via 1px high, 2px+ wide images. Using the smart bg function these qualifying images would optionally be generated in a separate image file, to allow repeatability and also to maintain minimum file size, however options like these are fully customizable depending on how you prefer your output images in case you wanted them included in the packed image. (More on this later)
Final image: 72.4K.
Final image area in pixels is 93120 (240 * 388)
*Please note that my blog post software doesn't seem to like the PNG alpha in these images, but I assure it's there - click the image to open it and see for yourself. Also of note here is the detection of per-pixel alpha in the source images and producing the correct image format out.
Here is the resultant image from a similar online sprite generator:
Final image size: 84.8K. Final image area: 482880 (240 x 2012) - also note there seems to be some unexpected behavior around a few alpha-blended buttons, but I'm sure this is being addressed, or is already addressed, at the time of this post, stuff like this is relatively minor.
So you can see how this packing can be beneficial - the whole idea here is to clamp down on extraneous client requests to the server, but also to reduce the overall bandwidth (and subsequent load times) for images from our sites. The packing saved 12.4k for the same set of input images.
Example CSS and XHTML gets generated as well, with some good comments and recommendations to those might be a bit confused about this code, or how to use it in their project. I'll discuss this aspect of the SpriteGen next.