wrong xrefs in help file

[Z__Bulova]

Hello, everything was going great until I had to add a chapter to my book that wasn't there before. It is actually an appendix. Now, all of my references to this appendix are wrong.

I just do not understand what is the problem that RoboHelp is having, because Framemaker is having no problem whatsoever in getting my references right and Framemaker never has had any problems in the xref area. Why isn't RoboHelp just using Framemaker to keep track of its xrefs? Instead, RoboHelp appears to be doing its own thing in the xref area and it is getting the xrefs wrong.

I have a number of xrefs to this appendix. These xrefs are pointing to the wrong appendix *in RoboHelp only.*

Here is some more detail.

I know that Framemaker uses markers to keep track of its xrefs. So I went into the appendix that RoboHelp *thinks* is the right appendix and I deleted the xref markers there. Then, when I force an update, RoboHelp stops thinking that it is this incorrect appendix and it thinks that it is *another* incorrect appendix. I go into FM and delete these markers. Then RoboHelp thinks that it is yet another incorrect appendix. RoboHelp basically appears to be moving up my chain of FM files. Maybe I should just keep deleting the markers until RoboHelp happens to hit the right file. But this certainly seems arbitrary, doesn't it??

This really makes me doubt whether RoboHelp is capable of keeping track of any xrefs at all. RoboHelp just does *not* seem to have a good method of keeping track of xrefs, at all, based on what I am observing here.

I am running TCS 1 and I am fully up to date with my patches. I happen to have a copy of TCS 2 running on a separate machine. I tried all this out with the TCS 2 (also fully up to date) and there RoboHelp just simply crashes every single time that I try to force an update: fully reproducible.

Also, I tried renaming my CPD file and running this whole process again on both TCS 1 and TCS 2...that did not affect my problem at all.

One thing that I observed on TCS 2 is that this new appendix shows up in my list of linked FM files, and it also has its own directory there, as well. Why is this? There is nothing inside of this directory. This empty directory was added after I renamed the CPD file.

If anyone has any ideas about how to resolve this problem, I would like to hear them.

Thanks in advance for your suggestions,

Z.

[Keith_dk]

Hi Z,

I had similar problems. I was using common files in several FM books. All the x-refs worked within FM but after the files were imported to RH some of the links pointed to the wrong files.

My solution was to get hold of XRef Wizard from West Street Consulting (see link below). XRef wizard functions as a plug-in in FM and simply appears in the menu bar - It works a treat. I run the wizard on my FM book before I import it to RH. All my xrefs become unique within the book. I find that the 8 character setting is sufficient, but it can handle longer markers if necessary. No more problems!

Link to west street: http://www.weststreetconsulting.com/WSC_XRefWizard.htm

Good luck kb

[Arnis Gubins]

FYI, Xref Wizard is a great tool by Russ Ward, but it only works on structured cross-refs. So if one is using unstructured FM, then it won't help.

[octechwriter]

What do you do if you're using unstructured content?

I've noticed a couple of cross-references, which are correct in FrameMaker and the PDF, point to the wrong destination in roboHelp. There are probably others that I haven't noticed. Any advice?

Using TCS2 on Windows XP.

[rgcombs]

I encountered the same problem. Like octechwriter, I was using TCS2. The problem is not in RH, but in FM. Or maybe RH just isn't as clever as FM. 🙂 It seems that FM doesn't get tripped up if two Cross-Ref markers are identical (same marker text) as long as they're in different files. (It looks like the duplicates are the result of copy/paste operations.)

RH, OTOH, gets tripped up by the duplicates, and all the xrefs end up pointing to just one of the identical markers.

To fix this, you have to find the duplicates and either edit their marker text or delete and recreate the markers. Add an Index of Markers (IOM) to your FM book, choosing markers of type Cross-Ref and selecting Create Hypertext Links. Then, in the generated IOM, find the marker entries that reference more than page number. Click the second page number to go to that marker. Either delete it or open the Marker pod/dialog and change the marker text. I had quite a few duplicates and decided it was faster and more foolproof to delete all the duplicates and then find and fix unresolved xrefs.

HTH!

Richard G. Combs

[Matt-Tech Comm Tools]

Yep, per SGML/XML/HTML specs, the markers should contain unique id's, which is a problem if you cut & paste

Structured FM helps to avoid this by creating an UniqueID attribute value for the XREF based on the location in a doc & time that it's inserted...but still not unique if you cut & paste!

-Matt

Matt Sullivan

director of training

roundpeg, inc.

888.266.0313 x.1009

714 585-2335 cell /txt/sms

skype: mattrsullivan

blogs.roundpeg.com

www.linkedin.com/in/mattrsullivan

twitter.com/mattrsullivan

twitter.com/roundpeginc

join me in a meeting now

[rgcombs]

Upon further reflection, I think FM is innocent and the problem is with RH. FM has always facilitated and encouraged reuse -- an FM file can be part of any number of books, and an FM flow can be imported as a text inset into any number of files. It seems perfectly reasonable to me that its developers coded it to accommodate markers that aren't unique across files -- that is, to use the file/flow information for disambiguation.

In any case, whether reasonable or not, that's how FM worked. It was the responsibility of the RH team, when working to integrate RH with FM, to understand the FM behavior and make RH accommodate it. They failed to do so, and it's a defect in RH, IMHO.

Richard G. Combs