Re: Conversion of Word documents to structured frame documents

[jeremy@xxxxxxxxx (Jeremy H. Griffith)]

On Thu, 8 Apr 1999 14:18:17 -0700 (MST), Dan Emory <danemory@primenet.com>
wrote:

>But Frame, although it is ideally suited for producing proposal documents,
>has little penetration of that market, and one of the main reasons is the
>need for Word-to-Frame round-tripping. Most proposal input comes from people
>who use Word. If the proposal group uses Frame or FM+SGML, their documents
>must be converted back to Word for editing/updating by the proposal
>contributors. And many US government agencies still require that proposals
>be submitted in Word or WordPerfect, even when submittals in PDF or HTML are
>also allowed. The increasing US government requirement for page-limited
>proposals imposes even greater demands on round-tripping, since conversions
>in one direction or the other might change the page count.

If you dissect the situation a bit more, though, round-tripping isn't
really what is needed here.  Reliable *export* to Word, either native
or RTF, is the main issue.  If the proposal group is using FM, they
need to use Word for review and possibly final submittal; we have many
customers doing exactly that, including some producing manuals to MIL
specs with Word RTF output.  But none of them need to go the other way.

If you are using Frame tools, you may get input from people using Word.
But you don't need that in Frame format.  For one thing, you don't use
it in big chunks; you are usually reorganizing and collating material
from several source docs, and it's easy to cut and paste as plain text,
which immediately takes on the properties wanted in the Frame doc.
When incorporating comments, you often read the material, then use the
information just acquired to rewrite your own text, your own way.  In
fact, many FM-using TWs *like* the fact that the *lack* of a good import
from Word lets them retain control of the proposal production process!
Nobody *outside* the FM group can say, "Just use this hacked-up version."

>I know of several instances where major Frame license holders have
>considered using Frame or FM+SGML in their proposal groups, but abandoned
>the idea because of the unreliability of the round-trip conversion process.
>In a pressure-cooker proposal environment, round-trip conversions must be
>almost completely free of errors, or the necessity for any post-conversion
>clean-up.

I think it does them a disservice to insist that round-tripping is the
"real" answer.  The fact is, FrameMaker is so much more capable than
Word that the only way to round-trip is to dumb down the use of Frame
to the level of Word!  And do you know what expert gave me a real clear
explanation of why that *had* to be so, Dan?  **You** did!  And you were
absolutely right!  I still have the paper around that you sent me last
year (or the year before?) that made that point real clearly...  ;-)

>Even when round-tripping is not a regular occurrence, it can still be a
>vital requirement. For example:
>
>1. Source data is often created in Word, and must be converted to Frame
>without introducing errors or the need for extensive post-conversion clean-up.
>
>2. Legacy documents in Word need to be converted to Frame, particularly when
>an organization first acquires Frame.

Both of these are true, and Frame's current import filters leave a lot
to be desired.  The third-party solutions aren't great; AFAIK, all you
have is Blueberry.  We may do one sometime, but it's not at the top of
our list, mainly because we keep thinking that it's so critical to FM
that Adobe will *have* to do the job right, next release.  Not so far...

>3. An enterprise's tools for converting to on-line context-sensitive help
>(e.g., HTML Help, WinHelp, RoboHelp, etc.) may require that the input be in
>Word or RTF, necessitating error-free conversions of Frame docs to RTF or Word.
>
>4. Documents created in Frame may have to be repurposed using Word (e.g.,
>training materials produced by departments other that don't use Frame.

And these show the need for good export filters.  Fortunately, there
*are* some; we cover most of the territory, and Quadralay covers the
parts we don't, like double-byte versions (Asian, CJK), and HTML Help.
I consider this need well handled, and frankly doubt if Adobe can
improve on what's available, even if they buy one of us.  <bg>

But... and it's a big but... import + export <> round-tripping!  The
difference becomes clearer when you look at specific issues.  Take
auto-numbers.  You can readily convert from Word's limited auto-num
scheme to Frame's, but going the other way is nearly impossible.  We
don't even try; we turn Frame autonums into ordinary text.  That works
fine for all our customers, since they use Word effectively as a print
format.  But it would be failure for round-tripping, as you wouldn't
get back in Word what you originally had in Word.

>In summary, Frame is still (and probably always will be) a niche product,
>which means that it is not widely distributed electronically in its native
>format. Presently, the only reliable conversion available within the
>FrameMaker product is to PDF, and even that conversion is often problematic.
>Conversion of FM+SGML structured docs to SGML or XML often requires
>extensive development. If the market for Frame products is to broaden, its
>capability for round-trip conversions to/from other formats must be expanded
>and improved. The most likely source of such conversion tools is third-party
>software vendors like SEMA, Omni Systems, Blueberry, Quadralay, and (in the
>case of SGML/XML) OmniMark.

By advising people to wait for round-trip solutions, one will only
deprive them of the advantages they could have today with Frame and
Word used asymmetrically... and they are waiting for something that
we have no intention of *ever* building, even if we do a Word import
filter for Frame.  It just doesn't meet a real need, and the cost in
resources is too high to do it for the esthetic aspects alone... <g>

>It now appears that Adobe plans to issue a major new release of Frame about
>once every two years (provided they can find a way to avoid bug-ridden point
>releases such as 5.5). Third-party software vendors of conversion tools are
>on a much shorter release schedule, because the nature of their business
>demands it. Adobe would be better off if it subsidized, or in other ways
>supported, those third-party vendors rather than trying to develop adequate
>conversion tools within the Frame product itself. 

Sure hope Adobe agrees with you!  A clear statement along those lines
would go far toward encouraging us to invest more in extending those
third-party tools.  As it is, we're always wondering if the next FM
release will provide "good enough" conversion to make our sales too
small to support product development.  This has held us back for some
time, both for HTML (which we only released recently) and for import.
We never know until the release is in our hands.

>Promotional deals could be
>struck that offered these third-party products at a deep discount to Frame
>license holders.

I doubt it.  Frame license holders are our only customers anyway, and 
our profits on filter sales cannot be described as enormous... <vbg>
We do a shade better than break even.  I have no idea where those deep
discounts could come from... unless we raised our prices, which we have
no intention of doing.

Thank you, Dan and Marcus (and the other participants too), for an
interesting discussion and analysis of the whole import/export area,
an aspect too often neglected entirely...

--
Jeremy H. Griffith                        jeremy@omsys.com 
VP, Software Development             http://www.omsys.com/
Omni Systems, Inc.             California and Vermont, USA               

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **