- Flattening and Interactivity
- Comparison of Flash's Imaging Model and the Adobe Imaging Model
- Representing AIM in Flash
Both export formats aim to represent static InDesign content as accurately as possible, with emphasis placed on preserving the visual appearance of the source document. Because of the differences between Flash's imaging model and the Adobe Imaging Model (AIM) that's the foundation of PostScript and PDF, there are challenges in how to represent particular kinds of content when converting from one representation to the other. When facing these challenges, its typical to choose the option that gives the best visual fidelity, even if that means the structure of the underlying content is destroyed. For instance, text may in some cases be converting 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 formats is that SWF is a final form content, similar is some respects to PDF, that is not intended for further editing in a downstream tool, whereas XFL is, by its very nature, an editable format. This has two main consequences. First, it means that 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. This led two key decisions about how InDesign CS4 exports the two formats.
First, when exporting to XFL,InDesign CS4 does not include buttons, page transitions, or other interactivity features, or movies and sounds. The assumption behind this is that customers will most likely want to add interactivity like this in the Flash environment given the much better toolset available there - InDesign's interactivity tools are limited to simple buttons, page transitions and placed sounds and movies, whereas Flash offers ActionScript scripting, an extensive set of components, and more, on top of what InDesign offers. Support for such features in XFL export may come in future versions of the software.
Second, InDesign CS4 flattens all transparency when exporting to SWF. The assumption is that the SWF content will not have later edits that would benefit from the preservation of transparency. Like with PDF 1.3, PostScript/print, and SVG exports, flattening only occurs on spreads that have transparency, and makes use of the existing Flattener Presets to control the flattening options.
However, the two imaging models differ in a number of important ways. The complete list of differences is too large to include here, but some of the more important differences are:
- Flash uses device RGB color only. No other color spaces are supported and all color is uncalibrated.
- 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.
In the below content, if no explicit reference is made to a particular format, the assumption should be that the item refers to both SWF and XFL.
Paths are implicitly intersected with the current clipping path. For instance, if a rectangular path is filled with solid color and the current clip is an ellipse that fits exactly within the rectangle, the result will be a fill of the elliptical path. We will not represent this as it would typically be represented in PostScript, PDF or SVG, as a clip on the elliptical path followed by a fill on the rectangular path.
Dashed and dotted paths are implicitly converted to fills. The resulting path is compound and will be filled with a single call and not as a separate fill for each dash.
Raster images in the Flash imaging model fall into two main categories: lossy (such as JPEG compressed) or lossless (such as Zip or Flate compressed). In addition to these main categories, indexed can be considered a subcategory of lossless.
This distinction is muddied somewhat when authoring in Flash, which allows a number of raster formats to be imported to the library. Internally, however, Flash will ultimately treat the images as falling into one of the two main categories.
We use BitmapFill instead of Bitmap objects in order to ensure clipping works in all cases of images transitioning from InDesign CS4 to XFL.
We use this heuristic when determining what format to use when encoding a raster image as part of exporting to XFL:
* If the image source is a JPEG that does not require any modifications, such as color conversion or re-sampling, it is used as is. Note that this implies that the image has no alpha channel.
* For all other cases, we use PNG.
Note that these heuristics are also used when exporting to SWF, with a handful of exceptions (see below).
When exporting to SWF, InDesign CS4 uses the following heuristic 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
Alpha channel does not automatically require lossless compression as it does for XFL. 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 implicitly converted to indexed.
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.
I need to go back and determine exactly how the conversions are done. I believe that this is done using Newell blending for separation and DeviceN/NChannel color (rather than OPP) and that it is not a preserve numbers conversion for RGB content but I'm not positive about any of that. [Not sure if this is important for the sake of this document]
Simple opacity will be preserved.
Blending modes common to AIM and Flash are currently preserved in XFL export, assuming that the flattener is not invoked. However, there are outstanding issues around the use of transparency groups with blend modes that may result in incorrect appearance when imported into Flash Authoring.[Did these issues get resolved? Do they need to be noted here?]
Strokes with non-solid color, such as gradients, are converted to fills.
Note that gap color handling naturally follows these same rules. In InDesign, gap color is rendered by stroking the path with a solid stroke prior to stroking with the dashed (or other non-solid) stroke. Each follows the rules abovelikewise for striped and other stroke styles (e.g., slanted, diamond, wavy, etc.). These are rendered as multiple stroked paths, each following the above rules.
This is currently done by rasterizing the content in device space that is, we determine the bounds of the content in device space, and then bake any transforms on the content, rotation or skew, for instance, into the resulting raster.
Rasterized content will follow the resolution specified in the export settings.
- InDesign Text to Flash Text: Text will be represented as DOMTextObject when exporting to XFL so that it can be edited in Flash, or represented by DefineText tags when exporting directly to SWF.
- InDesign Text to Vector Paths: Text will be represented as path shape in XFL, or using DefineShape tags in SWF.
- InDesign Text to Raster Image: Text will be represented as raster images in XFL, or using Image tags in SWF.
When exporting XFL or SWF with the InDesign CS4 Text to Flash Text option enabled, all text in will be represented as static text objectsdynamic text is not supported. All fonts are embeddeddevice fonts are not supported.
Ideally each InDesign CS4 text run would be represented as a DOMTextObject in XFL, however, in some cases, the original text run must be subdivided so that each subrun can be represented uniquely. For example, if composite font has applied to a text run, we have to do this subdivision since XFL face attribute tag does not have the notation of composite font. Another case is that if text run has been applied tracking or kerning attribute, then we may have to subdivide the text run too if the letter space of each characters in the original text run is different.
Since XFL does not current support all text attributes that can be set in InDesign CS4, some text has to be converted to vector paths or rasterized to preserve the visual fidelity of the text. Below are some of the instances where this will occur, even when the option for InDesign Text to Flash Text is selected
Cases in which the text will be rasterized:
- Text has gradient applied
Cases in which the text will be converted to vector paths:
- Ruby text
- Kenten text
- Text with Small Cap applied
- Text on the path
- Text has stroke applied (both fill and stroke will be vectorized)
- Text has Gaiji/Sing font applied
- GlyphID and Unicode values do not match
- Many glyphs map to the same Unicode value
- Glyph cannot be represented by Unicode value
In addition, we decide to always embed fonts in SWF which means that character shapes will always be in the SWF file, so it's not necessary to convert glyphID to Unicode for rendering text in SWF because DefineText tag has reference to the glyphID in the DefineFont tag. Therefore the visual look of SWF should be the same across platforms.
As noted above, buttons and itneractivity features are not preserved in XFL exported from InDesign CS4. For that workflow, use Adobe Flash CS4 to add buttons and interactivity to your XFL project.
SWF export from InDesign CS4 supports a subset of buttons actions, page transitions, and other interactivity features. Button actions include a subset of those supported by PDF export. Some, like 'Quit,' 'Close,' and 'Open file' have no real meaning in Flash, and thus are not supported when exporting to SWF.
See note above for issues with transparency flattening and interactivity.
Currently, movies and sounds are not supported in either XFL or SWF export from InDesign CS4. For this workflow, export to XFL and use Flash CS4 to add movies and sounds to the project.
When exporting with this option to SWF, buttons and hyperlinks are not preserved. However, page transitions, including Page Curls, are preserved.