If you’ve got a brush tool selected, hold down ctrl + option (Mac) / alt + right click (Win), and then drag your cursor to alter your brush size.To then alter the hardness, you need to first release your mouse button, and then add cmd (Mac) or shift (Win) to the combinations above. Dragging your cursor will then adjust the brush hardness.

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.

Clipping Paths

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.

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.

This series of blog posts is aimed at giving you background on the technical issues and best practices relevant to exporting as SWF or XFL.

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.

Mumbai

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.