Interoperability; or Play nicely, boys

I'm back at work for a while now, trying to convince two very separate applications to play nicely with each other.

In the red corner (as it were) is Microsoft Word, the very commonly used word processor & text editor. In the blue corner is Adobe InDesign, the heavyweight page layout software.

Despite the similarities of the two, there are some really fundamental differences between them, going right down to the basic level of what the software is designed to do.

Word

Word is designed to make it very easy to type simple documents, apply some rough page and type formatting, and print it out or email it. Apart from a few character and paragraph styles, the formatting and layout options are pretty limited.
What Word excels at, though, is the process of writing the document. Find & replace is very good, with a useful selection of wildcards. A variety of forms of annotation are available, all relatively easily.

InDesign

InDesign, on the other hand, is designed to create very high quality printed output, with as much typographic and graphical integration as possible, and it excels at this. It's fabulously easy to create inventive page spreads with precise positioning of all the elements. It's a doddle to combine multiple documents as a single book, and link between them all seamlessly in whatever output you want to create.

The drawbacks

At some point in the publishing process, though, you'll need to take input from the authors (usually in Word or one of the alternatives) and put it into InDesign. This is where the problems begin to show.
InDesign doesn't handle the same number of annotation options, and anything that doesn't fit is just dumped out at the end of the document.
Word doesn't allow cross-references between documents, so unless you combine everything into one big lump, you can't end up with anything saying "See page xx", unless you want to manually update them all in InDesign later.

The solution?

Luckily, InDesign has a great scripting toolkit. You can write bits of JavaScript that do practically anything you like with the document, which is what we're doing now. The trick I'm finding at the moment is that you have to work out exactly what you want from the workflow before starting the scripts (which is a good first step for any project) and then build them up very slowly.
These packages may not want to play well with each other, but with a little thought and effort, you can certainly paper around a lot of the cracks.