FrameMaker 7.2 was announced this week (see our news here and Adobe’s home page for the product here). Our news story touches on many of the new product features, but a few things are worth highlighting. Overall, the release is a significant step forward for FrameMaker, and should be seen as very welcome news for organizations that rely on the product for technical publishing.
- The new release adds XML schema support. While Karl Matthews, Adobe’s Group Product Manager for FrameMaker, was careful to point out to me that the schema support does not extend to data typing, I think this is sufficient for the kinds of publishing applications FrameMaker users would develop.
- The product now includes XSLT support. XSLT transformations can be invoked at the time a structured FrameMaker document is opened or saved. This will enable, for example, a “save as” function that could invoke an XSLT transformation on an XML document to create other content sets, metadata extractions, and so on. This is a clever addition to the product, and gets FrameMaker developers away from being reliant on the FrameMaker SDK.
- The product comes with a starter application for DITA. This is also welcome news, as there is a groundswell of support for DITA, and an independent group had been working on a separate FrameMaker application for DITA. This gives FrameMaker users a DITA application supported by Adobe. Moreover, the FrameMaker DITA application reflects a great deal of work Adobe had done in-house using FrameMaker to produce the documentation set for Adobe Creative Suite 2. (For Adobe’s own case study of how they used FrameMaker for this project, you can download this pdf. A related case study at Idiom’s web site describes how FrameMaker was used with Idiom’s WorldServer technology to manage the localization of the documentation into many languages.)
- The new version also adds some additional features and functionality for migrating unstructured FrameMaker content to XML. They have a pretty useful Migration Guide here (pdf).
On the whole, I was impressed with what I learned about the new release. It has some important new structural features (schema, XSLT), and the DITA application is timely and useful to a growing number of potential users. The strength of this release should quiet some of the feelings among users that Adobe is not fully committed to FrameMaker. Moreover, at a list price of $699, FrameMaker continues to provide a great deal of value for its user community by combining XML editing, high-quality print publishing, well integrated support for Adobe PDF, and support for multichannel publishing.
I agree that FrameMaker 7.2 is a great step forward for structured, XML-driven publishing workflows. With XML schema and XSLT support Adobe opened a nice can of new possibilities (and finally the multiple undo is “nice to have”, too!).
However, FrameMaker still has one major drawback, unfortunately: The missing Unicode support. In a nutshell this means, that it is (out of the box) impossible to process any non-western languages – i.e. all languages that use charaters not provided in the windows codepage 1252.
This contradicts Adobe’s claim of positioning FrameMaker as the tool for xml-based, structured and global (i.e. multilingual) document publishing engine. Actually, you cannot translate or publish a structured FrameMaker document via XML and Unicode e.g. in Greek, Russian, Turkish or any of the central european or baltic languages. And even worse: On import of Unicode-XML content in these languages all characters will be placed into “unknownchar” markers (a pretty sad solution, but at least the unicode chars do not get lost). But, frankly, editing a 500 page technical documentation wich has not a single character but only markers does not make any sense at all. Not to mention, that you cannot even properly sort an Index in any other language than English and a couple of western languages. Not even the spanish, swedish, norwegian, danish and dutch index collation is correct out of the box – while Adobe officially suppports these languages with FrameMaker.
However, there are a couple of possibilities to workaround FrameMaker’s inability to handle Unicode with hacks like registry based virtual font mapping and with a big bunch of additional tools, FDK plugins and/or FrameScripts. And at least the major translation memory companies have built in mapping tables to map unicode charaters in their translation files to the restricted FrameRoman codepage. And as long as you do not plan to read or write Unicode-XML for “non western” languages you can more or less (actually less) live with the missing unicode support.
But with some distance all the existing workarounds are only a desperate struggle to make Adobe’s unredeemed claim for a global document publishing engine reality. Isn’t it a farce that fortune 500 companies working with FrameMaker are using “patches” (actually FrameMaker.exe hacks) from the Slovak and Czech underground to be able to show at least the t-Caron character which is used in every third word in the slovak language and in the czech language or to make FrameMaker display specific cyrillic characters? Or that fortune 500 companies use hacks, patches and plugins to create proper PDFs with Unciode bookmarks? Or that people use dialog (UI) patches so that FrameMaker dialogs can at least show some “longer” Font Names like “Times New Roman”?
Personally I regard FrameMaker as the best publishing engine on the market when it’s about large scale technical documentation and if you only have to deal with western languages and don’t need xml. But the changed global political situation and companies’ need to publish documentations in up to 30 languages today for a global market, require a publishing engine that fully supports unicode. Adobe is still missing an answer to this.
Best regards,
Stefan Gentz
TRACOM, Germany
DITA and the Beatles
CM Professionals founding director and all-around great guy Bob Doyle has a cute take on DITA in the current EContent…
Have you seen this FrameMaker and XML / DITA event in the UK. http://www.mekon.com/adobe
Its being held at Adobe UK offices
FrameMaker and XML Pulishing
DITA and FrameMaker 7.2
I have a pretty lengthy entry over at the Gilbane Report blog on the new release of FrameMaker and its support for DITA….