Re: Sharing conditionalized files across books

[jeremy@xxxxxxxxx (Jeremy H. Griffith)]

On Wed, 19 Apr 2000 20:22:50 -0700, Robert Hartman <hartman@epiphany.com> wrote:

>Hmmm ... I didn't think you had to do this, but just to be sure, I tested
>it.

Er, so did I...  ;-)

>Here's what I did: 
>
>First, I verified that I had no markers in my files.
>
>Next, I imported the inset file.  I then opened a third, empty file, and
>added an x-ref to the container that pointed to a paragraph in the inset.
>The marker appeared in the container file and the x-ref worked. 

Right, so far...  You did notice that the marker did *not* appear in
the inset file, right?  Just the container?

>To be sure that the x-ref survived a change in the pagination of the inset,
>I forced the inset to a new page by adding some text above it.  I then
>updated x-refs in the third file. The page number changed appropriately.
>Apparently, when the entire inset moves, FM gets it right.

Yes, if you make a change in the container file that does not affect the
inset, that is, any change except deleting the inset, nothing changes
about xrefs to the inset.  That is not a surprise.

>I tested further by forcing a pagination change to occur as a result of
>additions to the inset file.  Sadly, that change invalidated the x-ref to
>the container.  

Right.  If the xref to the inset happens to be at the very start of the
inset, it stays there... even if you insert material at the start, in
which case it becomes a reference to the *new* material.  Surprise!

If the xref to the inset is anyplace else, it just disappears entirely.
You now have an unresolved xref to it with the text it had originally...
just the problem my "extra steps" avoided.

>Unfortunately, the x-ref also gets broken when there is a
>marker in the inset file. (I tested that too.)

Wrong.  I don't know what you did in your test, but had you followed my
directions, your reference to the marker in the inset via the container
would remain valid through any changes in the inset file.  That was my
whole point.  Maybe you tried to connect as a "paragraph" instead of a
"marker", and as a result got a new marker in the container file instead.
Did you look at the inset file to see if the marker was really there?  If 
you followed directions, it would be, because you created it in step 1.

>So, the upshot is that there will be unresolved x-refs to fix when you make
>changes to the inset file that alter the pagination of the container. But at
>least they're obvious, unlike conditional-text complications. I guess that
>the workaround is to generate a list of them whenever you update the book.

Bad advice.  You can avoid creating broken xrefs if you take the added
trouble to create a marker *in the inset file* first, then reference it
as a marker, not a paragraph (which ensures you get the one in the inset
file, not a new one in the container).  Then you don't have to worry about
fixup from a (possibly very long) list; nothing is broken.

Anyone who wants to test further is welcome to a little demo of this at:
  ftp://ftp.omsys.com/pub/insetref.zip
which contains three .fm files with self-descriptive names and contents...
in Windows FM 5.5.6 format.  Open all three in FM together.  Have fun!

-- Jeremy H. Griffith, at Omni Systems Inc.
  (jeremy@omsys.com)  http://www.omsys.com/

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