Slashdot Mirror
Adobe Frame Maker Equivalent for Linux?
Sim asks: "I currently work for a company which has used Frame Maker on SGI/IRIX systems for almost 10 years (meaning they have roughly 10 years worth of FM documents/reports/technical narratives/etc). It appeared that there would be a clean sweep of old SGI's out the door in favor of PC's running Linux, until a very nasty glitch got in the way: Adobe discontinued it's work on a Linux version of Frame Maker -- leaving the project in a beta format. The unstable format of the current Frame Maker version makes putting it into a production environment nearly impossible. I was hoping someone out there might know of a really powerful Frame Maker substitute."
"This substitute would need to have the following features:
- 'user friendly' GUI
- should be able to handle document management (with document cross refrencing links)
- graphics support
- import tables/create table
- handle multiple template styles (a style manager for creating templates would be wonderful)
- should be able to import/open .DOC formats as well as export/save to .DOC
- STABILITY
Your first step is to face a simple nasty fact: you will not find a third-party tool that lets you edit your Frame files. Lots of vendors claim to have foolproof filters for WP formats, but it's all smoke and mirrors. The formats are too complicated, and there's no simple mapping between them. So you only have two choices: find a way to continue using Frame, or make a big one-time conversion of all your files into another format.
The first choice is one I personally would avoid, mainly because I really dislike Frame. But it might be more practical. There are various ways you might go about this: buy everybody VMWare licenses and use it to run the Windows version of Frame. Keep some of your SGI boxes around just to run Frame. (Since Unix Frame is an X app, you should be able to run it remotely. If this doesn't work, there's always terminal servers.) Or run Windows Frame on top of WINE.
In your position, I'd prefer to get away from Frame's proprietary format once and for all. Yes, I know, I just said that foolproof filters don't exist. But if you're willing to invest the effort (a lot of effort, I'm afraid) you can use advanced tools to do a one-time conversion.
The leading tool for this is Webworks Publisher. A limited version, which might be adequate for this task, is provided with FrameMaker 6.0. Pick a convenient XML schema, define a mapping between that schema and various Frame styles and formats, and there you are.
Once you have your documents in XML, you have a lot more options. You'll probably have to do a second transformation to a format of your choice. Why? Two reasons. First, the big XML authoring vendors seem to have no interest in Linux. (You might find something from a small vendor or in Open Source. But I've been thoroughly underwealmed by the offerings I've seen.) Second, your users will probably balk at becomming markup wonks. Not everybody want to think about document structure every time they dash off a memo.
Fortunately transforming XML into other formats is not a big deal.
Advocates of Abiword and similar programs will protest. Abiword uses XML as a native format. Why not just go directly from Frame to that format?
The problem is that the Abiword schema is a "data" schema -- it's all one big packet of rich text, with no attempt to isolate formatting. It's like RTF or MIF, only easier to parse. So when you transform something into Abiword XML, you're going to lose any information that Abiword doesn't know how to manage.
But Abiword might be a good choice anyway. It claims to have an XML/Docbook filter. If that woirks half-decently, you can transform your frame files into XML/Docbook (which is a very rich format, so you'd probably lose very little information). Keep your legacy files in that format, and import them into Abiword as needed. If Abiword proves unable to handle some of your more complex files, you can look at other alternatives.
Which is the great beauty of XML. If your current XML app isn't working out, there's always another one.
Which is not to say that XML is a magic bullet. XML transformations are tricky. A lot of XML technology is still under development. And, as Abiword and HTML demonstrate, you can't assume that you have the full power of markup flexability just because your documents use XML or SGML syntax.
My organization is in exactly the same situation.
We've been running Framemaker on Sun's for about a decade.
Due to the superior raw price performance of the x86 platform, we will be moving to Linux over the next year.
We'd love to have Framemaker for Linux and would gladly pay for it. Many people feel it represents a superior offering for WYSIWYG document preparation compared to Microsoft Word, for example.
Unfortunately, it looks like Adobe is deliberately eroding its customer base for Framemaker on UNIX by not supporting Linux.
I expect our users will run Framemaker over the network via X windows from Sun servers if they really need it. Meanwhile, they will also probably start experimenting more with MS Word under VMWare (which connects well with Office Bees in the rest of the corporation), or try StarOffice 5.2 and, later, 6.0. A trend of the number of Frame users at our site decreasing year by year will continue and possibly accelerate as a consequence of Adobe's reluctance to bring out a Linux version of Frame.
Ever since they got bought out by Adobe I've had the impression that Framemaker is being managed in a short-sighted way. Either that, or there is a "bigger picture" with the rest of their products, etc. that I am missing.
However, with MacOS X, perhaps there's some hope that someone will see that "multiplatform support" in the UNIX world is no where near the bugaboo they fear from their years of experience with "multiplatform support" meaning Windows+Mac.
We'll do our migration to Linux with or without Adobe. Whether we do it with or without Framemaker several years from now is entirely up to them.
"Provided by the management for your protection."
Alternately, use Citrix Metaframe, and run framemaker on a windows server. That would probably be more expensive, less convenient, and so on. But if you need users to access other windows applications as well, it is a whole lot better than giving each user two machines, and having you administer them both.