Cross-References Broken In RoboHelp 10 Output

[ASnyder28]

We are using FrameMaker 11 to author our documentation. We have some cross-reference links that do not work when the FrameMaker book is imported into RoboHelp. Upon import, the href information is not included in the link in the HTML code. The text looks like a link, however. When the help is generated, the text is not a link.  The following is an example of a non-functioning link:

see <a>Link</a>.</p>

Here is an example of a cross-reference that is functioning correctly:

<a href="#XREF_90399_Heading_Text">Link</a>

There are no errors in FrameMaker. The cross-reference is updating correctly in FrameMaker. In addition, when a PDF is made form the same book, the cross-reference works in the PDF.

Troubleshooting steps I have taken:

• I have tried going to MIF and back for both the source and target documents.
• I have recreated the cross-reference and marker.
• I have tried linking to a heading cross-reference marker, as well as a manually create cross-reference marker.
• I have renamed the file.
• I have renamed the marker.
• I have used different cross-reference formats.
• I recreated the file by copying all the text to Notepad and pasting the text back into a fresh FrameMaker file.

None of the steps I have attempted have corrected the issue for the cross-reference I focused my troubleshooting on. I hope that someone can point me in the right direction to correct this issue.

[ASnyder28]

I suggest submitting a bug report:  https://www.adobe.com/cfusion/mmform/index.cfm?name=wishform

I have done this for this issue for my versions of RoboHelp and FrameMaker. I would be specific about the financial impact upgrading so soon would have on your organization and reference this forum string. Good luck and I hope it gets fixed!

[ASnyder28]

Also, I have TCS 4 and the issue we are having hasn't been fixed yet. Upgrading won't fix it at this point if you are experiencing the same issue I am

.

[A-Bel]

Thank you for your support.

The bug report for RH is done. But I can't refer to it. Perhaps Adobe is going to send me a link or a reference number...

The RH patch 10.0.1  isn´t the fix?  That's what I understand from MattRSullivans response.

I remain a bit puzzled

[ASnyder28]

I just applied the patch for 10 and ran help in a project that has the issue. I do not see any change in my output. I still have broken cross references. I have been in contact with Adobe and from my understanding the issue involving insets and cross references that I describe above has not been fixed. The patch may address other issues with cross references, but not our specific issue. Hope this is helpful.

[Matt S - Tech Comm Tools]

Actually, the patch resolved my issues.

It sounds as if there's an issue with xrefs within text insets, which doesn't apply to me. However, I tend to design around such limitations...living to fight another day!

Lobby for the increased functionality at adobe.com/go/wish (already done, I think) and then hurry up and wait to see if it makes it into the next version!

[A-Bel]

Seems to be not that simple. We will test it with the TCS 4 trial version. As we have a 2nd cross reference problem in another project without text insets, but with the same behaviour (all external cross refs unresolved after import/ link) there might be a 50% success.

[Guest]

I think I may be having the same issue. I'm using Technical Communications version 3. I have a huge FM book composed of many books - over 3,000 pages if it were printed. I'm linking to the FM file in RoboHelp (RH). No broken xrefs in FM, but when I go to RH, there are odd xrefs or missing ones. I keep updating both FM and RH without any success. So, I generated a list of cross-reference markers in FM.

This is what I think is causing this. Even though you're supposed to be able to link to the FM file and if all is ok with the FM book (no errors, no broken xrefs), everything should chug along in RH. But, NO, it doesn't. When I put in cross-references in FM, I do them by the paragraph. But then you can also see the actual marker text, which doesn't always agree with the heading text. This is what RH uses. So, if you're having these issues, check the marker text to make sure it matches the paragraph text.

Below is an example where I had updated the heading, but the marker didn't match. FM didn't care and didn't report a broken cross-reference. RH just displayed the xref heading but it wasn't a link. Very frustrating. I'm looking for a way to get the xref markers to match the paragraph headings.

This is the heading: EContent in the PAC Patron Account

    and this is the marker text: 28254:Heading 3: 3M eBooks in the PAC Patron Account - Items Out 768

[Jeff_Coatsworth]

@Curious 1 - There may be two things at play here – one is the length of your paths and filenames of your FM content – there’s an invisible limit of around 35 characters that causes RH to drop xrefs from FM if the combined path & filename is too long. The other is that there’s a bug if you have FM content in the form of xref, text inset, more xrefs – the ones before the text inset will “convert” fine, the ones after are busted. Also have a look at your Conversion Settings – how are you telling RH to treat your FM xrefs?

[Guest]

I know what's happening though it took me forever to figure it out. In FM if you go to View, Markers and see the list of cross-reference markers - not the xref pod but the marker pod - it shows the actual marker text. So, apparently RoboHelp was using this instead of the paragraph heading. When I put in the cross-references, I select the paragraph style, then update the marker - FM is all set, no broken xrefs. But, alas, RoboHelp (with a .chm output) uses the marker text or actually probably the marker number. So, it put in xrefs randomly - but it wasn't random, just extremely annoying (if you're supposed to be able to link to the FM document that says all the xrefs are fine). The interesting thing is this didn't happen with Web Help output. But, I have to create this huge, unwieldy .chm - customers need it.

I was posting to try to help spare someone else this time-consuming, time-wasting activity. Because I assume most writers would rather write than track down these problems with tools. I actually like FrameMaker, but RoboHelp is not user-friendly. So now, back to running this thing for the zillionth time. I'm on a deadline and the only writer working on this. Good luck in your endeavors.

[Jeff_Coatsworth]

You can tweak what text gets used in RH in your Conversion Settings – that’s why I was asking. For example, I’ve got a FM xref format that does “heading text on page yy”, but in the Conversion Settings, I change that from “[Source]” to “<$paratext>” to use that paratext building block instead.

[Guest]

Yep, I know. That's what I use in the conversion settings to take out page numbers and convert the Heading in Title format so it doesn't say, See xxxx in the Administration Guide. That doesn't do anything to the actual marker text, which isn't revealed anywhere. But, if it doesn't know what marker ID to use, it puts in odd things. Like I showed in the example, the heading once said ebooks, but since then it's been changed to eContent. The heading was changed fine, which worked with FM, but RoboHelp must use the marker text and couldn't match it up to the new heading. That's the crux of the issue - I've tracked it down finally. So I thought I'd share in case someone else has that problem. Now if there were a way to say update all my cross-reference markers to use the existing headings, now that would be something!

[Arnis_Gubins]

Thanks for pointing out this subtle difference in behaviours between FM and RH.

Curious 1 wrote:

Now if there were a way to say update all my cross-reference markers to use the existing headings, now that would be something!

It would be even better if the FM and RH programmers talked to each other, so that snafu's like this don't happen in the first place...

[Guest]

Thanks! I'm getting a bit shrill myself - ran the Help at 3:15 a.m. and had started at about 6: a.m., trying this and that. Part of the problem is the FM files have been around forever. I started working at the company 14 years ago. And we just started using RoboHelp last year. I know compiled Help that's installed with the Windows application is old technology. But, I'm still expected to produce the file - oh with nice context-sensitive Help too - and do it all alone. I'm tempted to throw up my hands and say we can serve up Web Help because that works quite well. But change is difficult, especially when initiated by a writer.

[Jeff_Coatsworth]

I realize I know why this has never been an issue with my FM to RH project – I don’t do the linking method – I just import fresh each time. The “out of synch” heading vs. marker text is completely ignored in that case. You always get whatever the heading text says.

[Guest]

Wow! That's very helpful. Maybe I should try importing instead of linking. I've already re-created the project several times, but I'm wondering if it would run more quickly. It takes so long now - to chug through and update all the files and then generated the .chm. It's painful. And, I can't work on any other FM files. I am working from home while I'm doing this. I'm up against it because there's a big general release of the software on the 15th. Thanks for the tip. I may try importing. I also need to convince my company that people are used to going to a web page for Help. I don't know about workform-level Help though. I guess that's the next thing to investigate if I'm not in the madhouse from working on this project.

[Jeff_Coatsworth]

I ended up using the import method because my FM content uses the “master book of books” concept and back in TCS2, linking couldn’t handle that. I produce WebHelp that’s installed on the client’s LAN server (so it’s considered to be locally-installed vs. really “online” with all the issues of browser-security paranoia that brings) and uses CSH calls from the software to deliver screen-level reference help.

[Guest]

I'm stepping through all the cross-reference markers. Select View, Pods, Markers, then sort by Marker type to see the xrefs. Select Special, Marker to see the text, go through the list in the pod and edit the markers to match the heading text.

The odd thing is that I don't think this was off when I generated WebHelp just to see. Many xrefs were off in the .chm. But then it was about 3 am and I'd been trying to resolve these issues since about 8 the previous morning, so I could've been seeing giraffes in my living room by that time.

[Alexandra Duffy]

We have a departmental policy that if you change a heading, you must also change the marker text for the heading. This is a pain because of course it causes the x-refs to break and they must be re-resolved. But it avoids the issues you describe. Also it makes it easier to add an x-ref to a destination because you can link to the x-refs in the list and don't have to use the paragraph for selecting the link.

It really would be great if there was an automated way of getting the marker text in sync with the heading text *and* not break the x-refs.

We have a large doc set too (over 2,000 pages) and yes, it does take a long time to chug through. But TCS4 and TCS5 are much more stable than previous versions.

Good luck getting your work done, Curious 1.

Alexandra

[Guest]

Thanks Alexandra, Unfortunately I'm on TS3. Good tip about the marker text. Some of these FM files are over 14 years old, so it's amazing they work at all. Various people have worked on them and changed headings. I'm going to try the importing instead of linking option. At least I was able to track down why the Xrefs looked fine in FM and were either not working or pointing to some unrelated topic in RoboHelp.