More than meets the eye

I've been working recently on a series of XSLT conversions for a big XML data set, and I'm really impressed with the stuff you can pull with that.

The job's been to take a whole load of bibliographic information from the backend of a publishing system and convert it to something which can be brought into a design package to quickly put together a catalogue. Of course, nothing is as easy as it should be, and there are a lot of little hurdles to this which - a year or so ago - would have had me running off, tail between my legs. (Actually - it *did* have me running away from the problem: I did try to write something to solve this, and entirely failed!)

But now, with a bit more thought and general XML experience, I've managed to find ways to get around all those problems, and now the biggest problem we've got is that there's a certain amount of inconsistency in the data itself. (It was all imported from some other system, and some of the data there is well over fifteen years old. And wrong.)

Generally, though, I'm amazed at the power of XSL stylesheets and what they can do to a piece of XML. Pretty much anything, really. You can even create functions within the stylesheet like any other kind of language, which is incredibly useful.

However, there are some caveats. (There always are.)

Now, as with many things, there are different versions of the stylesheet implementaton, and they come with different functionalities. Sadly, the design package in use (InDesign), will only support version 1.0. Which is a shame, because all the really cool features (the functions mentioned above, and some of the date/time function as well) only came in in version 2.

However, if you've got a bunch of data in XML format and need to repurpose it for something a little different, I'd recommend checking out the possibilities of XSLT. There are plenty of free tools available and it's not too hard to get the head round it. And it might just open up a whole new purpose to your data - or in this case, save a whole rakeload of time. And those are two very noble purposes.

Science: It Works.

With a little help from some very nice people over on the Adobe Forums, some of yesterday's problems are now (mostly) solved.

Yes, there are issues with importing Word files into InDesign; both packages have suffered from feature creep over the last couple of versions, so the integration of file types only gets harder and harder.

But what really solved the issue was the appliance of old-style scientific trial and error. Going through the processes that InDesign automates by hand, and working out which one of them was causing the error. As it turns out, ID isn't keen on long footnotes which split across three or four pages (you know what? I'm not keen on them, either!) and as soon as that was taken out, everything worked perfectly.

Once again, the principle of working through a process and breaking it down into the most basic steps you can find to figure out what's going wrong gives results. Excellent. Now I can get back to what I was supposed to be doing, and automating as much of the typesetting as I can.

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.