Re: Sharing conditionalized files across books

[jeremy@xxxxxxxxx (Jeremy H. Griffith)]

On Thu, 20 Apr 2000 10:45:05 -0700, Robert Hartman <hartman@epiphany.com> wrote:

>> From: jeremy@omsys.com [mailto:jeremy@omsys.com]
>> Sent: Wednesday, April 19, 2000 10:14 PM
>> 
>> 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.
>
>That's not what I saw.  I made an x-ref to the second page of the inset, and
>it remained stable after I moved the inset.

I don't really want to beat this horse to death, but the fog is thick
here... to mix a fresh metaphor.  <g>  If you "move the inset" by making
changes to the container before it (the *only* way you can "move" it), 
you are fine, as I said above.

You only have trouble when you *modify* the inset itself, then the
container doesn't know where to put its own marker any more in the
imported text, and you lose the ref.

>> 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.
>
>Yup.  I did all that.  However, when I made the x-ref to the marker, the
><$paratext> string went blank.  It said 'See "" on page 3.'  So then I
>changed it to refer to the paragraph, and the x-ref broke when I modified 
>the inset.

Very very strange.  If you could see the marker in the xref box when you
had the container file selected as source, and markers selected instead of 
paragraphs, then you should have had a stable link.  I am very methodical
when I do this stuff; I save after every change, for example.  Possibly you
got into an indeterminate state by not saving?  And you didn't say if you
could see the marker in the inset file itself, directly, a key point...
"did all that" isn't a helpful description of what you did, and I can't
see over your shoulder from here...  ;-)

>> 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.
>
>It was the best advice I could come up with, given the <$paratext> problem.
>Any ideas on how to get around that?

First I'd have to be able to recreate it.  <g>  Try listing an exact series
of steps, every keystroke (aside from text entry), that creates it...  I'm
not convinced yet that the steps I listed will ever fail if used as given.

Incidentally, this *is* the documented method on page 158 of the FM 5.5 User
Guide.  I just looked it up... I don't remember how I learned of it in the
first place, but I don't think it was from the manual, even though it is
there (without the reasons why).

>BTW, I appreciate the depth of your analysis.  It is really dismaying to
>have to go to such lengths to make things obvious.

Indeed.  This could have been handled in a much friendlier manner in
FrameMaker itself, especially the bit about keeping markers in the
container that reference inset material in sync if the inset changes.
In my test cases, for example, the Unique ID of the para where the
marker was placed did *not* change in the inset, so it could have
been found and used to resync when the inset was updated.  But maybe
the coders were in too much of a hurry for such niceties.  ;-)

-- 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.   **