Cross Reference displays wrong Chapter

[FM_JEN]

I have several FrameMaker files that will eventually be combined into one book. In some chapters there are references to outside chapters. At some point another person that was using these files had to switch the Chapter title; for example Chapter 7 became Chapter 6. Now when I open up, lets say Chapter 5, and I set up a cross reference to chapter 6 I got throug the following steps:

I make sure both files are open in FrameMaker, I put my cursor in the spot I want to make a hyperlink > Right click > Cross Reference

When the window Pops up I make the following selections:

Document: Chpater 6

Source Type: Paragraphs

Paragraph type: Heading1

Paragraphs: Page 7

I select the exact paragraph I want referenced

Format: CH XX, #

When I hit replace I am expecting the text on the screen to say something like "CH06, 3-1 Title" but instead it says "CH07, 3-1 Title"

The link goes to the location I want, it goes right to Chapter 6 but the visible text says Chapter 7 which is wrong. I assume this is happening because someone switched those two chapters.

Does anyone know how to edit what the text says or what I need to change in the switched chapters to make it work correctly. Something else I noticed is that the Document option in the cross reference is saying Chapter 6 with the old title, not the latest up to date title.

[Jeff_Coatsworth]

See my post in this thread about controlling how RH uses it - https://forums.adobe.com/message/6365508#6365508

[Bob_Niland]

To expand a bit on what Arnis said:

> ... FM only uses the marker text as part of a unique ID (<MText...> consisting of a FM generated number, the paratag and the string of the initial paragraph) and never actually uses the contents of the marker  for display purposes.

Users are almost never aware of the contents of auto-created and generated Marker text, and never see the Unique# unless they MIF muck.

> When the marker is first created, FM stuffs in the entire paratext into the marker by default.

... and almost never changes it or the tag name. The common case of encountering this is working with MIFs, which in our shop may contain no legacy tag formats, but appear to be loaded with them, because even though the formats were revised to current standards, that doesn't revise the marker text. The paragraph string often contains references to products and operations not even in the current manual, because the template for the manual was for another product, and the headings were merely edited, which does not usually change the marker text.

This means that any workflow tool or utility that assumes Marker Text tracks how it was created, or merely exposes generated/autocreated Marker Text to the user, is defective. Whoever wrote the code/script does not understand how FM actually works (vs. how we might like it to work), so you now have to wonder what else they screwed up.

That said, I'd still like to have Cross Reference [by Marker Text].

[Arnis Gubins]

AFAIK, FM never changes the target MText entry after it is has first been created, since it is used as a unique ID only. This is what the XRefSrcText item at the cross-ref insertion point looks for to find the content  to pull in as defined by the building blocks in the X-ref Format. That's why you end up seeing the old paratags and paragraph content.

I do whole-heartedly agree with you that there should be some mechanism to allow text defined in a marker to be used for the x-ref display string. However, just using the current x-ref marker would require a lot of retro-fitting in behaviours and expectations (i.e. it probably would break a whole lot of things). But if another (paired) marker type were to be added, analogous to the Glossary & GlossaryTerm behaviours, then it might be easier to implement. Le FM continue with the automatic/historical one and use the the new marker type solely for content display if present in the target area of the CrossReference marrker.

[Bob_Niland]

> AFAIK, FM never changes the target MText entry after it is has first been created, ...

I now agree with you. I had supposed that there were a couple of cases where FM might at least change the Unique#, but in testing, it does not.

One of those has yet another side effect that users need to be aware of. If you are copying in* content from another FM (or MIF, possibly MML) file that has identical marker text and unique numbers, FM deletes the duplicate markers rather than change them. This means that Xrefs in the copied material now point to that marker in the host document, and not the one in the incoming text. Usually this is what you want to have happen anyway.

On Xref by Marker Text:

> However, just using the current x-ref marker would require a lot of retro-fitting in behaviours and expectations (i.e. it probably would break a whole lot of things).

I'm thinking that just adding a Cross-Reference Building Block of <$markertext> would do the trick. Would you expect that to break things?

> But if another (paired) marker type were to be added, ..

I could work with that.

______________

* I didn't try importing (text inset) content with marker conflicts.