Links to external files don't work

[shuttie27]

Hello

Using RH 8.02 and converting linked Word docs (Word 2002) to WebHelp. These are policies and procedures that reference external documents.

In my Word doc I have a hyperlink to an external document. This doc is on a network server. In Word I added the hyperlink and it appeared as a relative path, such as ../RelatedDocs/RelDoc1.doc.

The referenced file is an external file, and I don't want to add it to RH because it may be updated; I just want to link to it so that a user gets the latest version.

When I update the HTML files in RH I see this in my HTML file:

<a href="file:////terminus/avbase_techsupport/av-base documents/supportmaster/documentationshare/relateddocs/reldoc1.doc">Related Doc 1</a>

This is the correct absolute path for the referenced file. Note the file://// prefix, with four forward slashes.

When I generate WebHelp, the link doesn't work. Nothing happens.

I tried the following:

1. Copied the whole path into my Windows Start > Run box and hit Enter. Nothing happens.

2. Removed two of the forward slashes and copied it again into the Run box. Now the file opens in Word.

I also tried removing the hyperlinks from the Word docs and adding them through RH instead. Same result.

Why does RH add four forward slashes to the prefix? What can I do to get these external links working?

Thanks for your help.

Roger Shuttleworth

London, Canada

[Peter Grainge]

You are saying when you add the relative path from the topic where it is on the server to where the document is located, RoboHelp is amending it?

How are you entering the link?

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[shuttie27]

Hello Peter

I apologize for taking so long to respond. I just received a new computer with Vista and have had to set it up. Here is what happens:

1. In Word, I have a doc policy1.doc that contains a hyperlink to reldoc1.doc. The two files are in different folders. When I insert the link, Word shows it as a relative path ../RelatedDocs/reldoc1.doc. When I hover over it in the Word doc, it shows as an absolute path starting with file:///\\theserver, etc.

2. My RH project includes policy1.doc but not reldoc1.doc. I update policy1.doc in RH. In the HTML topic file (HTML view) the link is:

<a href="file:////theserver/path/reldoc1.doc">Link text</a>. Note the four forward slashes.

3. I save all project files and generate WebHelp.

4. In the resultant web page (in Firefox), I click the link in policy1 and nothing happens. The status bar shows the path the same as above.

5. I navigate to the output !SSL! and find the index page, and open it in Internet Explorer 8. The link shows in the status bar as file://theserver/path/reldoc1.doc, and when clicked IE opens the Word doc.

So in this case Firefox doesn't open the link but IE does.

Here is another scenario:

1. I have no links in myWord docs.

2. I generate topic files in RH using the linked Word docs.

3. In RH, in the HTML file for policy1 (policy1.htm) I add a link to reldoc1.doc. I choose the file protocol. RH asks me if I want to copy the doc into the project folder, and I say No.

4. I check the HTML for policy1.htm and see that it has the link as follows:

<a href="file://J:/Documents/rest of folder path/RelDoc1.doc">Related Doc 1</a>

(Going to Hyperlink Properties shows the same path.) Note the two forward slashes.

5. I save all files in the project and click Generate Primary Layout (which is WebHelp). A dialog asks if I want to update <some file or other, but I can't see which one because that darned dialog box is too small, but I expect it's policy1.htm>.

6. I say No. The output is generated and I view it in Firefox. The link works and has a path in the status bar as:

<a href="file://J:/Documents/rest of folder path/RelDoc1.doc">Related Doc 1</a>
Note the three forward slashes.

7. I view the index.htm file in IE and it works.

As a variant of the above, instead of saying No when asked if I want to update the file, I say Yes.

1.The HTML of policy1.htm now shows the link as:

<a href="file:////server/rest of path/reldoc1.doc">Related Doc 1</a>

Note the four forward slashes again.

2. The link is as shown in the status bar of Firefox is now set to:

<a href="file:////server/rest of path/reldoc1.doc">Related Doc 1</a>
It doesn't work.

2. The same link shown in IE status bar has two forward slashes (even though the source has four), and it works.

So in answer to your question, the link definitely changes within RH. The two browsers deal with things differently, with IE seeing a file://// link as file://.

Incidentally, I did some research on the file:// protocol and came up with:

http://kb.mozillazine.org/Firefox_:_Issues_:_Links_to_Local_Pages_Don%27t_Work

The answer seems to be:

1. Add the links within RH.

2. Don't update when generating output.

3. If possible, get users to use IE instead of FF.

Either way, it's not very satisfactory for my purposes.

Regards,

Roger

[Peter Grainge]

Have I got this right? You have one document as a linked document in your project, that document has a link from it to another Word document and it is that link that is not working in FF but is OK in IE.

No surprise there as I would guess Word is writing the link in a format it understands and surprise surprise so does IE. Remind me whose products they are.

I haven't tested it but I doubt it would work even if you linked both documents as I doubt RH would change the cross document links. I could be wrong there.

Can you not change the link in RoboHelp? You would need to do that after each update but if it is only one link...

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[shuttie27]

Hi Peter

Your description of the scenario is correct. However, when you say, "I doubt RH would change the cross document links," it seems to me that that is exactly what it is doing. Both the file:// protocol prefix and the path change, depending on whether you choose Yes or No when it asks if you want to update the file. In the one case it uses the drive letter; in the other the server name.

Choosing Yes, the final result is file:////. IE reads this as file:// and works OK. Firefox reads it as file://// and refuses to open the link.

One option is for me to change all file://// links to file://///, which both IE and Firefox will open.

However, it's not really just "a single link". This is meant to be a system of policies and procedures that reference other documents (.doc, .pdf, etc.). Those documents will be updated from time to time, as will the policies and procedures. So every time I update my project I'll have to change all the links again.

It's doable, but not ideal. I guess my "real" question is why RH insists on creating links that use file://// when it is well known that Firefox won't touch them. If it used file:// or file:///// instead there would be no issue. (The other question is whether I can make it do that, but I guess the answer is no.)

Thanks again.

Roger

[Peter Grainge]

You are saying that RH amends the link you created in Word and that link is to another Word document. As only the first document is part of your project I am not clear how RH can know how to rewrite it but let's worry about that later.

When you create the link how does Word write it? How is the path written?

Then show how that gets amended in RH.

If that doesn't get us anywhere, I might need you to mock up a project so that I can see this happening.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[shuttie27]

Hi Peter

I should specify first that I am using Word 2002.

I described most of the process in my post of May 20th. But here it is:

I have two sibling folders, Policies and RelatedDocs. The Word docs in Policies will be part of my RH project; the ones in RelatedDocs will not, but will be linked to by my RH project docs.

1. In Word, I open my Policy1.doc and add a hyperlink to Reldoc1.doc, which is in the other folder. The link in Word Edit Hyperlink dialog box is: ../RelatedDocs/RelDoc1.doc (in other words, a relative path). When I hover over this link in Word, a tool-tip shows the absolute path to the Reldoc1.doc file, beginning with file:///\\ then the server name, path, and doc name. Note that at this point there are three forward and two back slashes in the Word format.

2. I add Policy1.doc to my RH project as a linked file, and generate my topic file. The link shows in Policy1.htm. In the HTML it is:

<a href="file:////server/path/reldoc1.doc">Related Doc 1</a>.

At this point, RH has changed the link from the Word format to an HTML format that contains file:////. This is the problem, because Firefox won't open a file link that has four forward slashes.

3. When I generate my output, the link in the resultant HTML file is the same as above, i.e. file:////server/path/reldoc1.doc.

IE will open this link because it handles file://// as file:// (which is what it shows in the status bar). Firefox won't open it, and shows file://// in the status bar.

Hope this clarifies things. I do appreciate your help.

Roger

[shuttie27]

I should also clarify my folder structure:

My RH project is on my local C: drive.

The linked policy docs and related docs are on a network drive. They are on the same drive, in sibling folders.

I have a feeling this may be relevant!

Roger

[Peter Grainge]

The workflow is clearer to me now but I think I will have to set something up to see this live.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Peter Grainge]

This is the test I set up.

On the D drive (a partition) I created two folders, each with a Word document. Doc 1 has a link to Doc 2

Hovering over the link is as below except for Z read D (I moved things)

In RH after linking and generating the topic, that gives me

Then I generate webhelp.

In FF the link is working fine except when you click it you lose the TOC.

If I choose to open it, it does open.

Clicking Refresh brings back the TOC. Not ideal but let's worry about that later.

Works OK in IE with no TOC problem.

I had the RH project on an external hard disk which I regularly use for RH projects. That's the nearest I can get to your scenario until I am back in the office Monday.

Create two new docs and a new RH project and copy the above as closely as you can. I want to see if it works the same for you or if you get a different result with a clean project and clean docs.

I was using Word 2007 and it's possible that does make things different.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[shuttie27]

Hi Peter

I repeated your setup and got the same result, with a couple of exceptions.

The HTML path is as you found, file://drive/path. Two forward slashes.

When I generate, the same path is in the generated HTML files. When I click the link in Firefox the status bar shows file:///drive/path (three slashes) but the HTML is file://. Firefox opens the doc in Word. No ToC problem.

When I open the HTML in IE8, the link doesn't work. The status bar shows file:/// (three slashes) even though the HTML source shows file://.

However, I think this setup is different from what I had originally.

1. If I understand your description correctly, you have your two Word files on a local drive and the RH project on a network drive. I had the opposite arrangement (which is what I would prefer for production): the RH project was on my C: drive and the Word files on a network drive.

With this latter setup (my original, which I just tried again), RH generates a link in the form:

file:////server name/path, with four forward slashes. After generating, this doesn't work in Firefox but does in IE.

By the way, one workaround I have is to run a variant of the Link Converter script, which changes the file://// links to file://///.

Have a good weekend. Monday is a holiday here in Canada, so I won't be online until Tuesday.

Roger

[Peter Grainge]

How very dare you suggest I would run a RoboHelp project from a network drive!

The Z drive with the project is an external USB hard disk that Windows treats as another local disk. The D drive is a partition of the internal hard disk. It's the nearest I can get to copying your set up where I am now.

On Monday I will move the documents to a network drive, relink to project, generate the help and see what happens then. One issue is going to be that the drive letter will not be the same for all users but that's a problem further down the line.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Peter Grainge]

Having tested with the documents on a server, I get your results so at least you know it is nothing you are doing wrong.

Looks like there are two steps for you.

1. A find and replace each time you generate. Perhaps not quite as bad as it sounds and at least it is a bug with a solution.
2. Report the bug. Please follow this link. http://www.Adobe.com/cfusion/mmform/index.cfm?name=wishform&product=38

Sorry it is not a better answer.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[shuttie27]

Hi Peter

Thanks for the information, and for confirming the result. Your help is very much appreciated.

I will report the bug. I think it will be easy enough to run a script that changes the URLs after generating.

Roger