Generated WebHelp with RH 7.0.2 is no more context sensistive

[vchugh]

Hello,
I have just updated RH to version 7.0.2. Now when I generate WebHelp and deploy it on a Unix server and call a particular help file form a Windows client, the wrong help page is dispalyed. When I click help, for a few seconds it points to the correct context sensitive help page, but when the TOC is loaded it goes back to the particular help page's parent folder. For example, I have a book called Window Descriptions and below that I have another topic called Create NE. Now when from the application when I click help for the Create NE page, it opens the Create NE page for a few seconds and after that it dispalys the Window Description page.
Any reason for this to happen. This problem was not there with the earlier version of RoboHelp (7.0). Is this a know issue. Any help on how to resolve this would be greatly appreciated.

[Peter Grainge]

And I suspect that if you hit the back button, the correct topic is then displayed. Yes?

I have reported this and indeed I set up a test on my site but using the latest FF update, that is resulting in a problem.

I am told that if you remove the string below from the output topics, it fixes the problem. I have not tested it.

setRelStartPage("../../index.htm");

If you want to test the demo on my site the address is

http://www.grainge.org/test/cshcall/startpage.htm#New_Topic.htm

but you might find you just get three characters. I would be interested to know what you do see.

[vchugh]

Yes if i click the Back button, the correct page displays. Also, could you tell me what exactly is to be done, because when I search for the string setRelStartPage("../../index.htm"); I do find it in any file, but when I search for setRelStartPage, I find it in many files.

The problem of seeing only three characters (), see my explanation below and how I resolved this issue:

The guess that Robohelp 7 started producing the output HTML files in Unicode (UTF-8) encoding formats. You cannot change this encoding. On further investigation, I found out that it uses 3 bytes UTF-8 BOM at the very beginning of the every file. To know more about this visit http://en.wikipedia.org/wiki/Byte_Order_Mark. These 3 bytes are invisible characters so you won't see them in any editor. The UTF-8 representation of the BOM is the byte sequence EF BB BF, which appears as the ISO-8859-1 characters  in most text editors and web browsers not prepared to handle UTF-8 and unfortunately FireFox cannot handle this. To actually see these 3 bytes open a htm file in Notepad ++ and click on the H symbol in the tool bar. These 3 bytes are optional bytes and browsers don’t require them to render a UTF-8 encoded HTML file. So what I did initially was to manually remove these 3 bytes from a few files and reload the page in FireFox. It worked fine. I found out that on a unix server we cloud do a search replace for these junk characters in all files of a folder including its sub-folders. So the final solution that worked for me is as follows:
1. Generate your WebHelp using RoboHelp 7
2. Copy the generated WebHelp folder to a Unix server
3. Start WinSCP to log onto that Unix server
4. Copy the script(name it replaceString.sh) onto that Unix server
5. Run the script (replaceString.sh)on the Unix server
Note: The location where you run this .sh file has to be changed in the script. For me the location was /ti_var/TI/http/help/en. Change this line to your location.

Here is the magic script:
#!/bin/bash
#Replace string in multiple files

for name in * ; do
if [ -d $name ] ; then
cd $name
echo "Replacing string in files from: $name"
/ti_var/TI/http/help/en/replaceString.sh
cd ..
elif [ $name != 'replaceString.sh' ] ; then
echo "Replacing string in: $name"
perl -pi -e 's// /g' $name
perl -pi -e 's/../ /g' $name
fi
done

Sadly this solution works only if you have acess to a UNIX server, because I guess Windows does not have the capability to serch and replace strings in mutiple files.

[Peter Grainge]

Interesting response.

I am having a different problem but potentially these BOM characters could be involved.

Visit this page using FF and the test opens

http://www.evergreenonlinelearning.com/webhelp/

Visit this page using FF which is using exactly the same output files and the help does not open, instead you just get the BOM characters.

http://www.grainge.org/test/test4/New_Project_Test.htm

Now logically, given the problem you see, I might conclude Unix is the issue. However, Both IE and Chrome can open the second link. So then you look to FF until you realise that FF can handle the same output on the first server.

I'll post anything I find.

[Peter Grainge]

As the problem I hit was different, this solution may not work but I guess it is worth a try. My webhost guy fixed things so that the above links now work. Here is what he advised me.

I would therefore conclude that the solution to this problem (on Linux systems running Apache) is to add the AddDefaultCharset utf-8 directive to either the Apache config or the site .htaccess file. The advantage of the latter is that it only affects individual sites). The default Apache character set is taken from the locale file on Linux and defaults to iso-8859-1. It is the conflict between the Apache header with iso-8859-1 and the page character set of utf-8 that obviously causes Firefox a problem.

[vchugh]

Thanks for the clue on BOM characters. I too would ask the dev guys here to make the change in the config file, but I need a solution for solving the problem I have with the help not being context sensitive anymore in FF. In your first reply you have said that if you remove the setRelStartPage("../../index.htm"); string below from the output topics, it fixes the problem. When I do a search of this string I do not find it in any file. Could you please tell me what exactly is do be done.

[Peter Grainge]

No, I said I had been told that fixed the problem, not that I knew it did.

Search on setRelStartPage. The name and path will vary according to your start page name and the page location.