Tim Cole's InDesign BackChannel

Ajar Productions has produced a free extension for Flash that combines multiple selected text frames into one text frame for easier editing.

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.

Posted by Tim Cole at 01:51 PM | Permalink | Comments (3)

Also new in InDesign CS4 is a completely re-written and re-architected Links feature. Some of the changes are obvious when you see the new look Links panel the first time you open it 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.

Posted by Tim Cole at 05:14 PM | Permalink | Comments (3)

The new InDesign CS4 SDK is available here. If you click on the Documentation tab, you'll find the links to the IDML documentation at the bottom of the page.

Posted by Tim Cole at 01:22 AM | Permalink | Comments (0)

XML is a beautiful thing...primarily for geeky people who are passionate about topics like workflow automation and industrial strength publishing solutions. Being able to describe document geometry and document content in a non-binary file format that can be edited and manipulated by databases, scripts, and other processes enables a vast universe of vertical market solutions that can save publishers a lot of time and money, as well as offer opportunities for new types of publishing products.

For the last few versions, InDesign has enabled you to export page objects or entire documents in an XML file format called .INX. It was designed primarily for backward compatibility, and it enables you to take documents from, for example, InDesign CS3 to InDesign CS2. What it was not designed to be was human readable...or easy to deconstruct, edit, and put back together again. Nevertheless, many third pary developers expended substantial effort to do just that simply because of the workflow opportunities afforded by a text only XML file format that would enable applications other than InDesign to create and/or edit document files.

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.

Posted by Tim Cole at 02:38 PM | Permalink | Comments (8)

Adobe InDesign CS4 contains a couple of powerful enhancements to Paragraph Styles. In addition to Nested Styles, CS4 enables you to apply character level styling on a line-by-line basis within a paragraph, or using GREP to identify and style runs of text. For example, you can use a GREP Style to automatically italicize any URL that appears in your text.

Here is the UI for Line Styles and GREP Styles:

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.

Posted by Tim Cole at 11:12 PM | Permalink | Comments (4)