« Gilbane Boston Conference | Main | More DITA: Another Interesting Case Study »

September 14, 2005

FrameMaker 7.2 and DITA

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.

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.

_______________________
Share or tag this post on:
Digg | del.icio.us | Google | Yahoo My Web | Reddit | Newsvine

Posted by Bill Trippe at September 14, 2005 10:12 AM

Trackback Pings

TrackBack URL for this entry:
http://gilbane.com/blog/mt-tb.cgi/159

Listed below are links to weblogs that reference FrameMaker 7.2 and DITA:

» DITA and the Beatles from Gilbane Report Blog
CM Professionals founding director and all-around great guy Bob Doyle has a cute take on DITA in the current EContent... [Read More]

Tracked on November 5, 2005 8:10 AM

» DITA and FrameMaker 7.2 from billtrippe.com
I have a pretty lengthy entry over at the Gilbane Report blog on the new release of FrameMaker and its support for DITA.... [Read More]

Tracked on March 23, 2006 11:40 AM

Comments

Please contact me to discuss the posibilities of this system.

Posted by: Leona Rubin at September 21, 2005 7:25 AM

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

Posted by: Stefan Gentz at September 27, 2005 10:41 AM

Have you seen this FrameMaker and XML / DITA event in the UK. www.mekon.com/adobe

Its being held at Adobe UK offices


FrameMaker and XML Pulishing

Posted by: LP at February 16, 2006 7:09 AM

Post a comment

Thanks for signing in, . Now you can comment. (sign out)

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)


Remember me?