Re: FrameToWord Conversion

[jeremy@xxxxxxxxx (Jeremy H. Griffith)]

On Tue, 13 Apr 1999 11:22:38 +0100, Claudia Oliver <Claudia.Oliver@TPS-Labs.com>
wrote:

>When including a reference to a header, a marker of type cross-ref will be
>set left to the header. When the header itself is changed or translated the
>marker text does not change. It's not a real problem because further
>references use this marker anyway. Isn't there still a way to automatically
>update these markers?

No, and there's a good reason for that.  FrameMaker uses the marker text
itself as the marker identifier.  If the marker text changed when you
changed the source text (the content of the heading, in your case), you
would break your links.  FrameMaker has no way to update the references
to your item, which may be in other files that are not currently open.
But, as you say, this does *not* affect the intended result, even though
it may bother you when you look at the markers in the xref dialog box.
Live with it.  <g>

>When converting a file with these references to Word using Omni Systems'
>MIF2RTF filter, the text of the reference marker is included in the Word
>reference. 

Only if you have Xrefs=Fields.  As we explain (in great detail) in our
docs, this setting is a "use at your own risk" option.  Instead, we tell
you to use Xrefs=Standard for Word, which makes FrameMaker xrefs into
fixed text, guaranteed to be the same text (and formatting) as in FM.

>When trying to update this a "reference source not found" error
>is popping up. How come? When checking the field codes I see that not only
>the original text is shown but part of the text is repeated (eg.
>BM74999Heading2Headeroflevel2level_2T where level_2T is the repetition or
>add-on). 

The basic problem is that Word doesn't have anything like the cross-
referencing capabilities of FM.  Not even close.  In a FrameMaker xref,
you can put together text, styles, and a slew of "building blocks" to
select just what you want, all in one chunk.  In Word, you get mainly
*one* building block, the contents of a named bookmark.  (You can also
get its page number.)  When autonumbers are involved, it gets worse,
as Word's abilities in this area are rudimentary and just cannot do
what even the simplest FrameMaker numbering scheme can accomplish.

Some time ago, in an excess of hubris, we thought that we could come
up with a clever emulation of FrameMaker's xrefs in Word.  After all,
we *did* that for sideheads, and run-in heads, so why not?  We spent
weeks of engineering on this one task before we had to concede defeat.
We had some success, especially with simple one-block xrefs, and so
we left the code we had developed, hundreds of lines of C++, in place,
but set it up to be activated *only* if Xrefs=Fields in mif2rtf.ini.

>Setting a new reference to a header in this Word file works fine
>and the reference can also be updated although the FM marker text is still
>included into the Word reference in cases where the header had been changed
>or translated in the FM file.

Yes, as noted above, the identifying marker text does not change.

>We do not want to update each cross-reference manually in the Word file,
>though. Is there any other solution?

Why are you updating references in Word in the first place?  This is
a violation of single-sourcing design rules.  You make your updates
in FrameMaker, and run off Word versions as needed, in a few seconds.
Then your xrefs are always accurate; FrameMaker ensures that!

We need to be real clear about this.  Word is not FrameMaker.  We have
done many clever things to create an *image* in Word of what you have
in FM.  But we cannot always make that image *work* as it does in FM!  
The code just isn't there, in Word, to do that job!  For most of our
customers, this does not matter.  They use Word for review copies, and
crank the reviewers' changes right back into FrameMaker.  The fixed
xrefs (and autonumbers) work just fine for them.

Now, you may be so unfortunate as to be working for Dilbert's boss, and
migrating to Word, not returning to Frame (sob!).  Then you may want to
use simpler forms than our "images" in Word, that you can *work* with in 
Word.  Fine; we support that way too, to the extent that it is possible.
That's why we left the Xrefs=Fields code in; it gives you a start toward
the Word way of handling your xrefs.  But it is only a start, not an
off-the-shelf answer, which does not exist in this case.  Anywhere.

We hope this clarifies the issues a bit, and helps others in avoiding
unrealistic expectations about Word, and about what filters can do...

-- Jeremy H. Griffith, at Omni Systems Inc.
   (jeremy@omsys.com)     http://www.omsys.com/
** To subscribe to Free Framers, email the message **
** body "subscribe framers" to majordomo@omsys.com **

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