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.
Subject:RE: DITA: going from FrameMaker to oXygen From:David Artman <David -at- DavidArtman -dot- com> To:Rebecca Officer <Rebecca -dot- Officer -at- alliedtelesis -dot- co -dot- nz> Date:Wed, 12 Dec 2018 19:26:33 -0500
I've been disappointed for years by the use of EDDs and non-DITA XML in
the tech stack of FrameMaker.
I'm certainly going to burn a bridge on this post; but why invest
development time and expect user admins to massage a production
pipeline, when Adobe money could have fixed the OT, and their tool
developers could have put Oxygen on alert? Is Adobe so committed to
their sandbox that they have to 'win' on proprietary features instead
of crushing on quality applications?
I might be either ignorant or a dreamer, but my understanding of DITA
is that it wants to be a standard divorced from tools. I've drank the
Kool-Aid of single sourcing across enterprises. I'm all-in on utter
accuracy through reuse and canonical sources of truth. I literally
think that the future of the internet depends upon such standards. I
work hard for a company that uses similar XML data-exchange frameworks
to solve problems that, unsolved, result in the death of humans.
And we have to co-support each other to use an interface, with
proprietary requirements, to attempt to build that ideal. Delivering
utterly outdated, undynamic formats to benighted clients on EVEN OLDER
paradigms.
Sorry if I dropped a bomb at a tea party. I probably should have
blogged.
But, man, it's just sadly shocking to me, and I've thought about this
state of affairs for a decade... and here it is.
David
[DCA:d.a.d.]
On Dec 12, 2018 18:53, Rebecca Officer
<Rebecca -dot- Officer -at- alliedtelesis -dot- co -dot- nz> wrote:
Hi Chris
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
.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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
You are currently subscribed to TECHWR-L as
rebecca -dot- officer -at- alliedtelesis -dot- co -dot- nz -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 http://www.techwhirl.com/email-discussion-groups/ for more resources
and info.
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
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
