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.

Image Format

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.

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.

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.

The focus of this first blog post will be positioning the two different export methods. What are they for? InDesign's SWF export is aimed at facilitating the creation of interactive presentations, client pitches, and personal portfolios. It's aimed at traditional print designers who wish to use InDesign as a bridge into the world of basic interactivity, whether it's being used for a customer facing presentation, an internal document review process where a single spread or an entire book could be viewed in a web browser, or as a way to help prototype a more sophisticated interactive experience that will ultimately be produced using Adobe Flash.

InDesign CS4 has a remodeled Buttons panel new page transitions (including the definitive "page curl"), and hyperlinks. These interactive features can be built into an exported SWF file, and used to advantage in the use cases enumerated above. What Adobe is not trying to do with InDesign's SWF export, is try to make anyone believe that it's designed to compete with Adobe Flash. That would be rather silly. Instead, our first cut at a SWF export is designed to introduce traditional print designers to the world of interactivity in a pretty painless and accessible way. The SWF export dialog contains straightforward options for presenting the InDesign generated content and interactivity in a SWF file.

InDesign's XFL export, on the other hand, is designed for professional workflows in which InDesign is used as the basic layout engine, and then Flash is used to add high-end interactive features. SWF is a black box that cannot be opened and edited. XFL, on the other hand, is a native Flash file format than enables a Flash designer/developer to leverage all the power of Flash with a design that comes from InDesign. InDesign has a rich set of tools for layout and publishing: styles, text wrap, drop caps, etc.--all things that layout designers want to leverage whether they're designing for print or for an interactive experience.

In the past InDesign users have had to export layouts as JPEG files to move them over to Flash, or also add copy and paste in and out of Illustrator as part of that workflow. The new XFL export feature eliminates those limiting and time-consuming steps, and instead offers a direct way to move designed from InDesign into the powerful interactive world of Flash. Most text can be converted directly to editable Flash native text, rather than ingested as uneditable and unsearchable "piles of pixels", as InDesign Product Manager Michael Ninness puts it. The goal of XFL is deliver InDesign content as faithfully as possible, while preserving editability in Flash.

In the next installment of this series, we'll start to look into the technical details and background as a necessary foundation for establishing and understanding best practices for taking InDesign documents into SWF and XFL formats.

We saw many old friends in Singapore and made some new ones. It was great to see the local Adobe User Group represented, as well as a lot of other people I met for the first time.

Special thanks to the event crew we had in Singapore and KL. You guys were great to work with, and everything went off without problems (either that or you hid them very well ;^). Your work was much appreciated.

The Singapore event was unique in that it was the only event that involved costume changes. In Paul's case it was onstage. Paul was given a special gift by event organizer Mongchee, and it added a touch of class and theatricality to Paul's web session.

I expect that more photos of the event will emerge that will prove embarrassing to all of us.

In Singapore I was able to show something new (and hidden) that got the Tamil speakers in the audience a little excited.

Finally, I wanted to say a special "thank you" to the person who gave me a very thoughtful gift. At first I thought it was something arranged by the local Singapore team, but later I learned that this was not the case, and that it was from someone who attended the event. I tried to locate this person later in the day to express my appreciation, but it appeared that they had already left the building. So, if the person in question is reading this blog, please accept my apology for not thanking you adequately at the time, and don't hesitate to identify yourself so that I can make up for my mistake.

My final event for this trip to Asia will be a presentation at the Fuji/Xerox Platinum Partner event in Macao on the 24th. Meanwhile, Michael Stoddart and Company will be doing CS4 launch events in Beijing and Seoul.

The stage in KL was fun, because we were able to come and go through doors behind the presenter's table. This enabled Karl and I to assist Paul whenever we felt that interest in his demo was flagging. As everyone there in attendance will attest, Paul is rather shy and a bit of a wallflower.

Several people in KL walked away with fabulous lucky draw prizes, including one very lucky individual who won a Master Collection.

Did I mention we had a great time with our friends in KL? We truly did, and we're very appreciative of the work that went into organizing the event. Best KL audience ever for me. I'm looking forward to the next time.

After the event we made our way over to Alor Street in KL for some fine dining at a local street eatery.

We had an opening act in Mumbai.

After lighting the lamp, the CS4 demos began.

Brave souls in the front row.

The Mumbai event was unique in that I was able to demo something special for them that I will write about in a later post.

Hong Kong

We had a big hall in Hong Kong. This is how it looked before we opened the doors.

In Hong Kong and Taipei, we had our first encounters with the pong bong stick (aka, bang bang stick, people's tube of joyful acclamation, etc.), a curious, inflatable plastic tube used to express affirmation and enthusiasm. There was much bong bong as Paul, Karl, and I showed off the new CS4 products.

Taipei

Taipei, you rock! We had to split the crowd into two room in order to accommodate everybody. More bong bong, and a lot of fun to get to present to our good friends in Taipei. (See Jimmy Hsia's blog post for more [and better] photos.

Just part of the crowd in Taipei...the upstairs crowd. There was another enormous collection of devoted Adobe users in the downstairs room.

Some of our front row friends in Taipei.

And, of course, when one is in Taipei, one must drop in to the Wind restaurant there, and order at least one bowl of fly heads. And, for the record, there are no actual fly heads in a bowl of fly heads...or, at least there shouldn't be.

For a little more information on fly heads--as well as an action photo of the dish--go to the Foodite site and scroll down to the entry dated Wednesday, March 22nd, 2006. I should have taken my own photo, but in the heat of the moment I was far too consumed with actually eating my fly heads to think about posing them and recording the moment with my iPhone.

Next up for us, Kuala Lumpur and Singapore!

This extension will definitely be of interest to InDesign CS4 users who plan to migrate layouts from InDesign into Flash via InDesign's XFL export feature. Text frames from InDesign will usually get converted to single line text frames in order preserve InDesign line breaks. This is great if you don't plan on doing significant revisions to the text content once it's been imported into Flash, but not great if do. This free extension--voted "most useful" at the Flash Camp Hackathon--will be a God-send to those of you planning on using the InDesign to Flash workflow in CS4.

There's some great new functionality in the Links panel in InDesign CS4, but that's not what this blog entry is going to be about (you can see the Links Panel in action in our Caffé Fibonacci program on Adobe TV).

In this post, I'm going to describe some powerful new capabilities that Adobe is providing under the hood for developers.

The Links re-architecture project delivered some great new hooks in the API's for developers to do a number of things relatively easily:

• link to database records or individual fields
• create bi-directional links so that edits made to linked text from a database in InDesign can be saved back to the database
• link to non-page items such as swatches, fonts, workspaces, etc. Links are no longer limited to files or other external assets masquerading as files. A link can now be to any internal object or external data source.
• create compound links and link queries via parent-child link relationships. A child link is a link that is a child of an import, export or bidirectional link. A child link always references an owner object through its parent link. An example would be InDesign CS3's ability to create parent-child links when an InDesign file is imported into another InDesign file. The parent link is the placed InDesign document, and the child links are the linked files within that document, and they can be viewed in the Links panel.
• make link queries (and link resource queries) that enable quickly obtaining a set of links with certain attributes from the link manager. For example, you can query for all import links that are out-of-date. The link manager does not need to iterate over the links to obtain the set, since it has already cached meta data on the links that allow it to quickly get the list of links. This is especially important for documents with several links, where iteration would be very time time consuming.
• use asynchronous link state updating
• link to files that do not yet exist, but are coming later in the production process.
• link to data contained in something other than a discrete, static file. For example, a developer can create links streaming data when reading
  or writing links.

InDesign CS4's new Linking architecture makes it a lot easier to create solutions for various types of publishing workflows. If you're interested in learning more, download the InDesign CS4 SDK, and get plugged in to our developer program.

What third party solution providers wanted to be able to do with .INX are things like:

• Programmatically create .INX outside InDesign, i.e., create InDesign document files using a database or some other application
• Edit or transform document
• Programmatically replace old with new content
• Extract and recombine document subcomponents
• Include and preserve their own proprietary data in the .INX structure
• Validate the .INX document structure
• Pre-flight the .INX code
• Execute processes on INX using industry standard tools like XSLT, XQuery, E4X, RelaxNG validators,  and converters
• Build rich internet applications that serve as front ends to a publishing system that uses InDesign Server as the layout engine.

Because INX was not designed to be used in these ways, and because Adobe did not officially support it, building workflows around .INX was challenging at best. Many dedicated developers, however, did just that, doing their best to work around the format's obstacles and limitations.

IDML

With the release of InDesign CS4, Adobe has delivered a new document XML file format that is actually designed to be a developer tool. IDML is the best thing since sliced bread for third party solution developers who have been wrestling with the inadequacies of the INX for building web to print and other workflow automation solutions. It's designed to be everything that .INX was not when it comes to supporting third party development.

DESIGN GOALS

The primary design goals of IDML are:

• Completeness: Any object, attribute, or preference can be represented in IDML. Complete "round trip" compatibility is expected of IDML files.
• Readability: The IDML format is human-readable, IDML is designed to be read and written by virtually any program or tool capable of reading and writing XML.
• Robustness: Developers have more visibility to errors and increased flexibility in handling them as well.
• Backward compatibility: A user will be able to take an IDML file generated for version X and open it in version X-1
• Performance: IDML aims to maintain or exceed the performance of INX.

We’ve designed IDML to make it a key part of automated workflows. Using IDML, you can:

• Programmatically generate or modify IDML documents
• Re-use parts of IDML documents in other documents
• Break a document into components
• Transform document elements using XSLT
• Find data in InDesign documents using XPath.

READABILITY

Here's a small sample of IDML code to illustrate the human readability, part of the description of a text frame:

<ItemGeometry NumPath="1" GeometricBounds="31 31 571 751" TransformationMatrix="1 0 0 1 5 -391">
<GeometryPath NumPoint="4" IsOpen="false">
<PathPoint AnchorPoint="31 31" LeftDirectionPoint="31 31" RightDirectionPoint="31 31"/>
<PathPoint AnchorPoint="31 751" LeftDirectionPoint="31 751" RightDirectionPoint="31 751"/>
<PathPoint AnchorPoint="571 751" LeftDirectionPoint="571 751" RightDirectionPoint="571 751"/>
<PathPoint AnchorPoint="571 31" LeftDirectionPoint="571 31" RightDirectionPoint="571 31"/>
</GeometryPath>
</ItemGeometry>

SUPPORT FOR THIRD PARTY DATA

IDML supports the inclusion of new scripting objects and properties added by 3rd part InDesign plug-ins. This means that third parties can embed their own proprietary data, any features added by plug-ins that support InDesign scripting can be included in the IDML package.

IDML EXPORT PACKAGE

When you export a document as IDML, InDesign creates a Zip archive containing multiple XML files.

The InDesign document is split into separate files representing different aspects of an InDesign document so that you can more easily identify and perform operations on the objects and properties you need. Document resources, spreads (page geometries), and stories are stored in different XML files within the zipped package.

LEGACY FORMATS

So, what becomes of INX and all its variants in past InDesign and InCopy workflows? First, here's a list of XML formats supported by InDesign and InCopy CS4:

Terminology

• IDML – InDesign Markup Language
• ICML – InCopy stories will be InCopy Markup Language
• INCD – old style InCopy story format used from InCopy 2.0 through CS2
• INCX – CS4 will have inport/export support for INCX
• INX traditional – the old style format that the INX clients have used from CS through CS3

INX will continue to be used for backward compatibility for InDesign versions prior to InDesign CS4.

IDML will be used for backward compatibility between InDesign CS4 and future versions.

Note: CS4 has no export support for INCD; however, we will continue to support INCD import.

The advent of IDML as a developer technology is a major development in the history of InDesign. We expect IDML to be leveraged extensively by third parties to deliver innovative and powerful publishing solutions to the market.

If you're a developer interested in learning more about IDML, you can do that do that through our developer partner program.

These features give rise to a practical question: if a nested style, line style, and/or GREP style overlap, which formatting gets priority?

According to the composition engineer:

There can be ranges of text that have overlapping character styles
applied using GREP styles, line styles & nested styles all interacting.
If the style definitions don’t clash, they will ALL apply. For example,
if the first line is all-caps (line styles), and the first word is bold
(nested styles), then the first word will be both all-caps & bold.
Pretty trivial example, but they can stack. In the case where there is
a clash, the choice is pretty fixed:

Line-styles are lowest priority

Nested Styles are next

GREP styles are top priority

If you have multiple GREP expressions that match the same text, then the
styles will still stack, and the order of the expressions in the dialog
controls this.

A colleague here at Adobe shared this link with me, and I thought it was cool enough to post here. This is a rather wild example of how to make useful signage on 3-D surfaces.

Eureka Carpark Melbourne

There's a new product available now from FoldRite that's designed to take the worry and hassle out of setting up different types of folded documents in InDesign. I played with it a bit the other day, and I found it to be both a valuable and easy to use utility. If you create folded printed pieces, you'll definitely want to have a look at this one, because it just might eliminate a lot of headaches for you.

The product is available in two forms, a plug-in utility (available at a discounted price of $299 until July 31st), or as a hosted online service where you can construct and download a template for $9.99.

You can find an animated online demo here that shows you how the interface works.

You use the animated interface to select and (if necessary) modify the settings to create the template you need. FoldRite creates new InDesign file that contains the rules and marks required to construct your job.

The finished product is an InDesign template that's ready-made with the required fold guides and markings necessary for printing and folding your document.

One of the very cool features of the plug-in version is its ability to "update" (remodel, really) an existing document. Suppose you're half-way thru a project that you're not sure you've set up correctly. You can run the FoldRite plug-in on an already existing InDesign document to get the correct setup applied to your file.

We’re also noticing, however, that some users are still hitting a problem that was introduced by a VersionCue 3.1 update last year. For a subset of users, the update did not install the VersionCueUI framework. As a result, when invoking a NavServices dialog (i.e., place, relink, save as, etc.), they will crash--not because of a Leopard problem, but because their VersionCueUI framework was not updated.

If you've installed 10.5.4 and are still experiencing a crash when invoking the Place or other system navigation dialogs, then please review the information below.

We’ve had a Knowledge Base article on this VersionCue updater issue late 2007. We have sent the email below to users that have sent us crash logs in the past couple months:

You’ve recently submitted an InDesign crashlog for a crash you hit when attempting to open one of the system file dialogs (Open, Place, Save As, Export, or Relink). The cause of this crash is a failed installation of a VersionCue update. Here is a link to an Adobe support webpage that will give you some more detail and a solution:
http://www.adobe.com/go/kb402521

If you area also running MacOS 10.5 (aka Leopard), I highly recommend that you get Apple’s latest update, 10.5.4, which was posted yesterday. To get this, choose “Software Update...” under your Apple menu. This latest update fixes another common case of InDesign unexpectedly quitting when attempting to access these dialogs in Leopard.

Finally, earlier today, Adobe posted an update to InDesign CS3, version 5.0.3, which fixes several critical bugs in other areas of the product. To get this update, choose “Updates...” under the Help menu in InDesign CS3. Alternatively, you can download the 5.0.3 updater from: http://www.adobe.com/support/downloads/detail.jsp?ftpID=3961

Thank you for submitting crashlogs. Although we cannot respond to every submission, we review them regularly and work to address the most serious issues.