Re: DITA: going from FrameMaker to oXygen

Subject: Re: DITA: going from FrameMaker to oXygen
From: Chris Despopoulos <despopoulos_chriss -at- yahoo -dot- com>
To: <techwr-l -at- lists -dot- techwr-l -dot- com>
Date: Mon, 10 Dec 2018 10:32:56 +0000 (UTC)

We've gone from FrameMaker to oXygen for DITA.
First, I have to say that both Maker and oXygen use the DITA OT... There's nothing about Maker that keeps you from using the OT. For output, Maker provides extra workflows because you can use its HTML and PDF publishing. In fact, we still use Maker to generate PDFs. There is simply no better way if you worry about the quality of your PDFs. You can set page breaks, and meaningfully review the document before you generate the PDF. On the down side, this is time consuming... Nothing is free. If you want exquisite PDF, you have to take the time.
OTOH, we also use oXygen for some PDFs... Mainly release notes at this time. oXygen has a concept of a "scenario", which is really a configuration for an OT transform. But they now have a concept of a CSS-based template that you can attach to a scenario, and you can use that CSS to generate PDF output. So that's much easier than using XSL-FO... Well I guess it is because I could never get a toe-hold on FO -- life is short. Page break control is truly inadequate, but we take the hit. The convenience of just running a transform to get the PDF is worth it.
For HTML, we never used Maker to get our official HTML -- we use an in-house process. The HTML that Maker produces is clunky in my opinion... It's based on RoboHelp publishing, and the final output is not something you can consider modifying. So unless you can coerce the publisher to give you exactly what you want... Well I tried to fight that fight a few times and gave up.Â

oXygen HTML is pretty good. They give you a number of ways to set it up, ranging from vanilla OT, to preset OT plugins, to their concept of CSS-based templates. The HTML output is less obfuscated than RoboHelp output, so if you need to tweak it after the fact it's easier to do. But again, we don't use generated HTML.

AUTHORING:FrameMaker added SGML/XML on after the fact. They did an excellent job of mapping markup to the Maker doc model. But the fact remains, there are still gaps. Most of them are handled by a Maker plugin that intervenes when opening/saving DITA. The bad news there is that if you want to handle LightWeight DITA, then you have to code some changes to handle gaps that appear in this different flavor of DITA. The RW rules don't cut it alone. I used Maker extend script. See Leximation for a product that goes further to fill in these gaps.
One thing that bothers me about Maker is that it changes the underlying DITA code. Diff for DITA is hard enough... Maker renders Diff meaningless. Some of our XML has to go through a code review process, and that requires DIFF... Had to remember NOT to use Maker for those files. Likewise the DITA map files... Maker knows better than you how they should be structured. We cannot save our map files in Maker because (wisely or not), we rely on a simpler structure than Maker likes.
Probably the thing I like best about oXygen for authoring is how they handle projects. They're essentially Eclipse projects (as in the Eclipse IDE). The experience is just more streamlined. I know Maker added a concept of projects in the latest release... Haven't checked it out. But the basis for projects in oXygen is quite mature, and oXygen doesn't add a lot of things that constrain a project. I just plain like it.
LICENSING:Adobe licensing got too complicated for me. If Adobe just sold a product, along with a maintenance plan, we would probably still be a Maker shop. I love Maker, I have worked with it for decades, I made bread and butter from it. I can program the FDK, and FrameMaker extend script, and have made many tools (freeware, some for sale, and many custom jobs). My relationship with FrameMaker is longer than any other relationship I've had outside of my blood relations.

I was the lone writer, and as we brought on other people, licensing became an issue with the company. Add in the fact that if you have gaps in the team (somebody leaves and it takes a long time to fill the spot), it gets ridiculous to track -- you have to pay a subscription for a vacant seat? Our wrestling matches with Adobe over licensing just weren't sustainable in a startup environment, where somebody has to stop actually working in order to convince them (Adobe) to let you use the tool. oXygen licensing is old fashioned and easy to deal with. Yay. So now we bring in new writers, and we get them oXygen. That means I'm the only person who can produce our PDFs. Sadly, this will change, and we will ultimately use oXygen for all our PDFs in the near future.

Hi everyone

Have any of you converted from FrameMaker to oXygen for authoring DITA? We're considering doing so and I'd really appreciate hearing about what people like and loathe about the change.



Visit TechWhirl for the latest on content technology, content strategy and content development |


You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-

To unsubscribe send a blank email to
techwr-l-leave -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot- Visit for more resources and info.

Looking for articles on Technical Communications? Head over to our online magazine at

Looking for the archived Techwr-l email discussions? Search our public email archives @


Previous by Author: Re: Preferred Sentence Structure
Next by Author: RE: DITA: going from FrameMaker to oXygen
Previous by Thread: Re: DITA: going from FrameMaker to oXygen
Next by Thread: RE: DITA: going from FrameMaker to oXygen

What this post helpful? Share it with friends and colleagues:

Sponsored Ads