Subscribe to Dr. Macro's XML Rants

NOTE TO TOOL OWNERS: In this blog I will occasionally make statements about products that you will take exception to. My intent is to always be factual and accurate. If I have made a statement that you consider to be incorrect or innaccurate, please bring it to my attention and, once I have verified my error, I will post the appropriate correction.

And before you get too exercised, please read the post, date 9 Feb 2006, titled "All Tools Suck".

Saturday, December 09, 2006

Typefi Publishing System: May not suck

One of the encouraging things I saw at XML 2006 is the Typefi Publishing System (TPS).

TPS is a plug-in to Adobe InDesign that attempts to automate the process of bringing XML content into InDesign in the most automated way possible. It does this by providing extensions that allow designers to indicate, within InDesign, what components of their page templates are dynamic and will be filled with imported data. You can also define sophisticated rules for dynamic placement and copy fitting that the TPS engine then uses, along with heuristics for layout aesthetics, to create the best page layout it can. TPS then provides an XML format that you can convert your documents to (using XSLT or whatever). The TPS-specific XML data is then imported. However, TPS claims to be able to preserve the mapping back to the original markup so that you can make content changes in InDesign and push them back into the original input (we'll see--that's the aspect of this system about which I'm most dubious given some inherent problems in doing that kind of round tripping).

At least that is the promise.

I only saw a demo and talked to the Typefi guys at length so I can't say whether what they showed really works but if it does it's pretty amazing stuff. There are more features of TPS, including something to do with Word, but I didn't pay attention to those as I'm completely focused on XML-based publishing workflows.

I've spent the better part of the last two years trying to implement the automation of publishing of highly-styled documents using high-end typographic systems (in my case, 3B2) so I am painfully familiar with the inherent challenges in automating things like the placement of figures and sidebars relative to their anchors and automatic copyfitting. It's a hard problem and if Typefi has done at least as much as I have (which it looks like they have) then they have done something of real value.

What they demonstrated, which included the system used by Lonely Planet Books, was pretty impressive and I had no reason to believe that it was not genuine.

You can be sure that I will be looking into Typefi more deeply for application in Innodata Isogen's composition practice, as well as an option for our professional services clients who want in-house automation of publishing workflows where XSL-FO is not up to the task.

Dr. Macro says check it out.


Adobe MARS: Looks Interesting

I just returned from the XML 2006 conference in Boston and saw a few of interesting things, including a presention on Adobe MARS and the Typefi product.

In this post, I want to talk about Adobe MARS.

MARS is an XML-based format that is intended as a functional replacement for PDF. It's not really accurate to call it an XML version of PDF because it's not a simple transliteration of PDF into tags (which could be done easily enough) but a ground-up exercise in designing and XML-based scheme for doing what PDF does.

After seeing Adobe's presentation and talking to the guys from Adobe it's clear that what they've done is a sincere and well-thought-out attempt to Do The Right Thing rather than a cynical recasting of proprietary stuff into markup so it's "open."

MARS tries to use standards as much as it can and it seems to do so to a remarkable level of completeness. It uses SVG for representing each page, supports the usual standards for media objects (bitmaps, videos, etc.). Uses Zip for packaging, and so on.

Philip Levy, the chief engineer for MARS, did appologize that they had to add a few extensions to SVG to handle some high-end typography stuff that isn't in SVG but said that if you were, for example, using MARS for office documents that you could get by with pure SVG.

Within Acrobat, the user experience off MARS is identical to that for PDF: all the behavior and functionality is the same. There is a MARS plug-in for Adobe 8 (reader or professional).

From a creation and manipulation standpoint, the advantage of MARS over PDF is obvious: you can use all the usual XML infrastructure to create and manipulate the data. That would certainly make things like PDF data extraction easier. The use of SVG would make embedding foreign name-spaced data into the PDF much easier (for example, to preserve structural indicators from the original source, something you can do with PDF today but that very few tools do in fact do).

The Adobe guys made it clear that MARS is not intended as a replacement for the current PDF format--there's just too much installed infrastructure and dependency on PDF for that to happen quickly and MARS isn't 100% complete over PDFs features (mosly around support for high-end printing workflows, I would guess). But it seems reasonable to think that, like MS Office, Adobe will slowly raise the profile of the XML version of PDF until it can make it the default format rather than the alternative. But I would expect that to take at least five years or more, given the speed with which the publishing industry, in particular, changes (which is more or less glacial).

Dr. Macro says check it out.