Re: Conversion of Word documents to structured frame documents

[Dan Emory <danemory@xxxxxxxxxxxx>]

At 10:35 PM 4/8/99 GMT, Jeremy H. Griffith wrote:
>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.
++++++++++++++++++++++++++++++++++++++++++++++++++++++
But in a proposal environment, the contributors (using Word) have control
over content, and the proposal group is responsible for editing, formatting,
and production. As the proposal evolves, the contributors must often modify
their input because of the typical gyrations that go on as the analysis is
refined, and the comments resulting from review. The proposal group, using
Frame, can't wait for the final version to do their part, because that final
version is often received at the last minute. So, each contributor needs to
get, in Word format, the latest version of his/her contributions that have
been edited and formatted by the proposal group so that their next update
(in Word) is done on that version. It's an iterative process, requiring many
round trips, 
and no one has found a feasible way of doing it.
++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
>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."
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
As someone whose functioned both as a technical contributor to, and an
editor of, large technical proposals, deliberately making it difficult for
contributors to make changes directly in the latest edited version of their
work product available from the proposal group is the tail wagging the dog.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>>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.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
I don't insist, they do, because there's no feasible way for most of them to
put FrameMaker in the hands of all the diverse contributors to a large
proposal, and then train them to use it within the short period of a
proposal cycle.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>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...  ;-)
++++++++++++++++++++++++++++++++++++++++++++++++++++++
I know, and I still don't have the answer I'm looking for, which is a
round-trip conversion capability that doesn't require me to dumb down
how FrameMaker is used. Something like the RTF-DOC DTD might be the answer,
as follows: 

1. If the document was originated on the FM+SGML side, An API client could
be used, on export to XML/SGML, to fill in the values of the RTF formatting
attributes specified in the RTF-DOC DTD. This would replicate the FM+SGML
formatting, including font definitions and a ready-made stylesheet for use
in Word.

2. If the document was originated in Word, the SEMA rtf2rdc filter preserves
the RTF formatting information when it is opened in FM+SGML (another API
client would probably be needed to do that).

If both the Word and FM+SGML users employed the same font definitions and
stylesheet, it might be workable.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>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.
>
>------------------Snip
>>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.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
But if Adobe could get a good discount from the 3rd-party vendors
on bulk purchases, and then offered those products at a discount to
Frame users, you've got the kind of promotion I'm talking about.
Registered Frame users get a limited-time offer in the mail from Adobe.
The buyer calls an Adobe 800 number, charges the purchase to his/her credit
card, and a fulfillment house ships it. Adobe gets a way to boost Frame
sales (and maybe makes a little money off the 3rd-party software purchase),
and the third-party vendors get an easy, low-cost way to market their
products in higher volume. Those who don't buy during the offering period at
least learn about your product, and if they decide later to buy it, they pay
you retail.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>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...
     ====================
     | Nullius in Verba |
     ====================
Dan Emory, Dan Emory & Associates
FrameMaker/FrameMaker+SGML Document Design & Database Publishing
Voice/Fax: 949-722-8971 E-Mail: danemory@primenet.com
10044 Adams Ave. #208, Huntington Beach, CA 92646
---Subscribe to the "Free Framers" list by sending a message to
   majordomo@omsys.com with "subscribe framers" (no quotes) in the body.


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