Broken cross references in FrameMaker Responsive HTML5 output

[ch41785421]

I'm trying to generate Responsive HTML5 output using the Publish command in FrameMaker and some of the cross references are broken. Whether the link works depends on the order of the files in the FrameMaker book. If the cross reference links to a file later in the book, it works. If the cross reference links to a previous file, the link is broken. Has anyone had a similiar issue and found a fix?

[Jeff_Coatsworth]

What version of FM? Are you all patched up? I've not heard of that issue occuring, but be warned that there is a limit to how long the path & filename of the resulting HTML file can be without breaking the href= links (discovered that one when I was importing FM content in RH and some xref links on the same topic page would work & others wouldn't - once I shortened up the paths in my FM files, they worked just fine; I mention this because the FM Publish engine is using RH under the hood).

[ch41785421]

Thanks! I'm using Version: 16.0.3.979, which I believe is the latest. I'll try shortening the path & filename. But the same cross reference will work or not work depending on the order of the files in the book, I have not changed the path or filename. One of my co-worker's was able to get the cross references to work if the source file is open while generating the Responsive HTML. But this workaround does not work for every book. 

[defaultmdgbu8fseg0r]

Hi,
We are also facing this issue. I've tried the workaround you suggested, of generating the HTML with all the source files open but that didn't help. I realise too that positioning is key; like you found, if the target of the link is 'after' the current position in the HTML it works, and in contrast if the source of the link is 'before' the current position it fails. Have you been able to find a solution for this or have you raised a case with Adobe? 

[ch41785421]

Hello,

I found that shortening the path & filename and having the source file opened when generating the HTML works "most" of the time. You must do both workarounds. It is still not a solution. I have not raised a case with Adobe yet.

[defaultmdgbu8fseg0r]

The fact that the links are ok in the PDF output suggests there is an issue with the HTML engine. I have emailed Adobe Support as suggested by Pulkit. 

[Jeff_Coatsworth]

Is there any source control involved in this? The fact that it worked for someone else sounds like issues with fully checking out the FM files.

[ch41785421]

No source control. All files are local to our PCs. I'm wondering if there is some "hidden" setting that is set differently?

[Jeff_Coatsworth]

So you're each copying all the FM files locally to work on them (taking turns I hope)

[Sabarish Katta]

Even we are facing the similar issue in our project. 😞 

[pulkitn]

There are no hidden settings and cross-reference added in standard way should work as is in html5  , If you are facing any kind of issues while generating html5 on latest FM2020 patch , I suggest you to kindly contact Support team at tcssup@adobe.com .They will assist you best there .

-Pulkit Nagpal

[defaultmdgbu8fseg0r]

Thanks Pulkit.
I have now emailed Adobe Support.

[Matt-Tech Comm Tools]

I've found that the characters used in filenames and path names can cause EPUB and HTML to fail. Do you have non-alphanumeric characters in file and path names?

I've also found that manual hyperlink markers (using Specify Named Destination) will cause issues when non-alpha characters are used.

If they exist, try renaming files and folders to remedy.

-Matt

[defaultmdgbu8fseg0r]

Hi,

Thanks for this suggestion. I have now tried removing all hyphens and underscores from the path and filenames: 

But I still see the same behaviour in the HTML.

However, after spending some time with Adobe Support we have noticed something: if the target of the link is 'before' the current position but within the HTML output of an *.fm file, they work; whereas, if the target of the link is 'before' the current position and in the HTML output of a different *.fm, they do not work. I have tried to show this using yellow highlights (within an *.fm file) and pink highlights (between *.fm files). 

The Database Stored Procedures page opens but the Check the Pods and Check the Logs of the Pods pages do not.

I'm one of three writers, working in different places from each other, and on five products. We are all seeing this issue using FM2020. We are using book-in-book files to publish our document sets. But the problem exists for single guides too.  

We don't use manual hyperlink markers. We're fully paid up members of the 'Cross-Reference pod club'.

[ch41785421]

Yes, that is the same issue we are facing. If the target link is in the same *.fm file, it works. If the target link is in a different *.fm file "before" the current *.fm file, it fails. If the target link is in a different *.fm file "after" the current *.fm file, it works. Did you get any resolution to the issue?

[Nimisha_Aggarwal]

Hi @ch41785421 , @defaultmdgbu8fseg0r ,

Sincere apologies for the inconvenience that you are facing.

We have tried the mentioned scenario on our end, but not able to reproduce the issue. It would be really helpful if you could share some sample files having the issue. So that we can further look into it and assist you in the best possible way we can.

Thanks in advance for your support.

-Nimisha Aggarwal

[defaultmdgbu8fseg0r]

Hello @ch41785421 and Nimisha,

We thought we had a solution to this issue.

Adobe Support have been trying to help and have spent some time demonstrating that in their sample books the links work, even 'backward' ones between *.fm files.

The solution that worked while sharing my desktop in a call with Adobe Support was to make a new book file, save it, and then copy in the *.fm files from one of our guides. All the links in the HTML from publishing that guide worked. The conclusion was that migrating from FM2019 to FM2020 had corrupted the book file.

However, trying this out after the call, for another guide, did not solve the problem, the ‘backward’ links with issues still existed. In contrast, all the links did work for a colleague when they created a new book file for a single guide; but, when they created new book files for all the product’s guides and then generated HTML for the book-of-books, some of the ‘backward’ links were again broken (they display a blank white page in the right pane).

I haven’t actually updated Adobe Support about this yet but will do so now.

So, no, we don’t have a reliable solution that works for us. But maybe you could try creating new book files in FM2020 and see if that works for you?

It’s a shame though because this and https://tracker.adobe.com/#/view/FRMAKER-11062 is making our HTML output appear very amateurish.

[ch41785421]

I submitted a bug with Adobe concerning the broken cross reference links in the HTML output: https://tracker.adobe.com/#/view/FRMAKER-11221 

[defaultmdgbu8fseg0r]

Latest update: After another call with Adobe Support we realised we had not been using an FM2020 sts files to generate the HTML, instead we'd used an FM2019 one that we let FM2020 convert for the current release. Using an FM2020 sts has solved the problem of backward links showing as blank white pages (which is what we were seeing).

[Jeff_Coatsworth]

So did you have to recreate your settings in a new FM2020 sts file then?

[defaultmdgbu8fseg0r]

Hello,
Yes, we did. I took a copy of the <your_local_path>\Adobe FrameMaker 2020\fminit\Publisher\Default.sts and renamed and relocated it for our purposes. In FM2019 I opened an existing FM2019-based sts file (Publish > Settings File > Edit > Outputs > Manage Layout (Charcoal_Grey) > Edit). Alongside that, in FM2020, I opened the 'new' FM2020-based sts file and edited its settings accordingly. Having both versions open made the process of updating the settings file reasonably starightforward.

[Jeff_Coatsworth]

Just slightly annoying that it didn't upgrade/convert it for you...oh well.

[ch41785421]

I tried recreating the STS file, but it did not fix my issue. I did find that the issue seems to be related to the "Split into topics based on this style" checkbox in the Publish Settings form. If this box is checked for any paragrapgh style, links to previous fm files in the HTML are broken. If this box is not selected, the links work. Are you using this setting in your STS file?

 

[Matt-Tech Comm Tools]

Is this happening in the file you duplicated and repositioned?

If so, does the error occur when you create a new STS instead, before you do extensive work to it?

-Matt

[ch41785421]

I created a new STS file from the default. The only change that I made was the checkbox, as shown in the screen capture. Also, I used a very simple book with only 3 chapters. The fm files are based on our template, but I did not modify the STS file to map our paragraph styles.