Representing AIM in Flash
When InDesign exports into SWF or XFL, it needs to describe objects using the Flash object model, rather than the Adobe Imaging Model (AIM).
As a general rule, InDesign attempts to use matching native Flash constructs whenever possible, and when that is not possible, it uses whatever means available in Flash it can to maintain the visual appearance of the source objects in InDesign.
Suppose you have an image in a frame in InDesign. In InDesign you can modify the size of the frame that clips the image, and you can reposition that image within that frame.
In this example, the image is clipped by a frame with a white stroke.
When that object is exported to XFL and then opened in Flash, you’ll see that the image was cropped on export, and the white stroke is represented as a separate path object within Flash.
I’ve moved the image in order to make the fact that there are two separate objects in Flash clear.
Raster Images in XFL Export
InDesign exports a raster image to XFL as a path with a BitmapFill applied. This enables InDesign to clip the image to the path boundaries.
This differs from what happens when a raster image is placed on the stage while authoring in Flash. Within Flash, you get a Bitmap object. It is necessary to select the placed image, context click on it, and choose “Break apart…” to convert a Bitmap object to a path with a BitmapFill.
InDesign the BitmapFill instead of Bitmap objects in order to ensure clipping works in all cases of images transitioning from InDesign CS4 to XFL.
InDesign uses the following methodology when determining what format to use when encoding a raster image as part of exporting to XFL:
- If the image in the InDesign document is a JPEG that does not require any modifications, such as color conversion or re-sampling, it is exported in XFL exactly as it came into InDesign, meaning it is not re-compressed. Note that this implies that the image has no alpha channel.
- For all other cases, including when the user has resized a placed JPEG or applied a transparency effect to it (such as a drop shadow), InDesign will export the image(s) as a PNG.
- Note that these methods are also used when exporting to SWF, with a handful of exceptions (see below).
Raster Images in SWF Export
The methods used when exporting to SWF are similar to that for XFL, except that InDesign must choose between full color lossless, indexed lossless and lossy (JPEG) encoding.
When exporting to SWF, InDesign CS4 uses the following method to determine whether lossless or lossy encoding is used:
Lossless encoding is used if one or more of the following is true:
- The raster is a 1-bit bitmap
- The raster’s width times its height is less than 4096 (this matches SWF publishing from Flash)
- The raster has a chroma key*
- The raster is not considered “smooth”
A placed image in InDesign that uses an alpha channel does not automatically require lossless compression when exported to SWF as it does for XFL Export. Flash Player supports the notion of JPEG + alpha, in which the color pixels are JPEG compressed and the alpha channel is stored as a separate, Flate compressed block. If an image with alpha can be represented as JPEG, aside from its alpha channel, it will be stored in the SWF as JPEG + alpha.
If the raster uses 256 or fewer colors, it is converted to indexed color.
In all other cases, lossy compression is chosen.
*Chroma key is a way to selectively mask pixels based on a particular pixel value (compare to the transparent pixel in GIF). These are not expected in an InDesign CS4 workflow where we’ll be rasterizing the placed vector content that would be the only way to get such content into ID.