TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Thanks very much for that. The idea of being able to use the diffs is definitely appealing, and of getting better HTML. We don't use Frame for HTML, only for PDFs, and we'll probably keep using Frame for the PDFs.
Cheers
Rebecca
-----Original Message-----
From: techwr-l-bounces+rebecca -dot- officer=alliedtelesis -dot- co -dot- nz -at- lists -dot- techwr-l -dot- com <techwr-l-bounces+rebecca -dot- officer=alliedtelesis -dot- co -dot- nz -at- lists -dot- techwr-l -dot- com> On Behalf Of Chris Despopoulos
Sent: Monday, 10 December 2018 11:33 PM
To: techwr-l -at- lists -dot- techwr-l -dot- com
Subject: Re: DITA: going from FrameMaker to oXygen
We've gone from FrameMaker to oXygen for DITA.
OUTPUT:
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.
Thanks
Rebecca
------------------------------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | https://techwhirl.com
Looking for articles on Technical Communications? Head over to our online magazine at http://techwhirl.com
Looking for the archived Techwr-l email discussions? Search our public email archives @ http://techwr-l.com/archives
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Visit TechWhirl for the latest on content technology, content strategy and content development | https://techwhirl.com
