In this post I begin a more detailed discussion of the technical background of InDesign’s SWF and XFL export processes. This series will be based largely on a white paper researched and written by Adobe’s Matt Laun.
Both of InDesign’s Flash export formats are designed to represent InDesign content as accurately as possible, with emphasis placed on preserving the visual appearance of the InDesign document.
The imaging model in Flash is different than that of InDesign. InDesign uses the Adobe Imaging model (AIM) that’s the foundation for both PostScript and PDF, while Flash does not. Because of this, there are challenges and choices to be made when converting a layout from one model (AIM) to another (Flash). Whenever choices need to be made, the InDesign to Flash process will typically choose the option that produces the best visual fidelity, even if it means that something is lost in the process. For example, text may in some cases (like ligatures) be converted to outlines or rasterized, and dashed lines–which have no native Flash representation–may be converted to compound paths that are then filled.
One important difference between the two exportable formats is that SWF is a final form for delivery (similar is some respects to PDF) that is not intended for further editing in a downstream tool. XFL is, on the other hand, is, due to the fact it’s an XML format, designed to be editable format. This has two main consequences. First, it means that all interactivity for SWF must be added in InDesign, whereas with XFL it will likely be added within Flash. Second, it is much less important to attempt to preserve the original structure of the document for SWF. Because of this, InDesign treats the two types of exports differently.
Examples: Unlike a SWF export, InDesign CS4 does not include interactive content (like buttons and hyperlinks) when exporting to XFL. The assumption behind this behavior is that users will most likely want to add interactivity like this in the Flash environment given both the vast range of powerful features available there.
Second, InDesign CS4 flattens all transparency when exporting to SWF. The assumption here is that the SWF content will not have later edits that would benefit from the preservation of live transparency. As with PDF 1.3, PostScript/print, and SVG exports, flattening only occurs on spreads that contain transparency, and makes use of the existing Flattener Presets to control the flattening options.
Imaging Models: Flash vs. InDesign
Similarities: Flash’s imaging model is superficially similar to the Adobe Imaging Model (AIM).
- Both are vector-based and support the notion of paths that are filled/stroked with various kinds of painted pixels.
- Both support affine transformations (transformations which–like scaling, translation, and rotation–preserve the "parallel-ness" of an object’s lines). Both support raster images, including alpha channelsl.
- Both support vector text. Both support simple opacity and the notion of blend modes that dictate how content is composited with any other the content it overlaps.
The takeaway here is that most of the AIM representation of objects will largely transfer to Flash.
Differences: The complete list of differences is too large to include here, but some of the more relevant differences for this discussion are:
- Flash uses device RGB color only. No other color spaces are supported and all color is un calibrated.
- Flash uses quadratic curves, whereas AIM uses cubics. This requires that an authoring tool approximate its native cubic curves with quadratic curves.
- Flash paths implicitly use a non-zero winding rule. AIM paths may use either non-zero or even-odd winding.
- Flash supports a limited set of paint types: solid color, gradients, and raster paint are supported; more complex paints, such as general smooth shades, and patterns, are not.
- Flash gradients allow a smaller number of stops than their AIM equivalents.
- Flash supports limited clipping and masking. Flash allows objects in its display list to be clipped and/or masked by other objects in the display list, but this is a simple one-to-one relationship and limited compared to the graphic state based clipping and masking supported by AIM.
- Flash does not natively support dashed or dotted lines. These simulated in Flash by drawing each dash as an individual line segment.
- Flash supports a limited subset of the blending modes available in AIM.
- Flash does not support transparency groups.
Next time: how specific types of AIM objects are translated into Flash CS4.