Convert all calls to lowercase

[markusflow]

Hi all,

one of our customers with a huge "old" software and a lot of help buttons delivers an offline web help with its software.

Due to decisions from the past, each help button calls a html file directly. (we know, that a call like <path to help>\index.htm#topica.htm is recommended). The thing is whether the call is with or without "index.htm#":

Some buttons call the file in upper cases, some in lower cases:
<path to help>\topica.htm
<path to help>\TOPICB.htm

Lower cases works fine. The topic is also shown when calling the file in upper case, but the toc is not synchronised and the breadcrumb says "No TOC entry for this topic".

Unfortunately, they refuse to go through their code and unify all calls to lower cases and asked to fetch the call in the help file and convert it to lower cases. I think the magic of the reload from topica.htm call to index.htm#topica.htm is done in the jquery.history.js. I tried some changes without any success. Has anyone experienced a similar request and solved it?

[Tim Green]

Hi Markus,

The problem here is that you are on an Apache, Unix or Linux web server, in which all calls are case-sensitive. Since all filenames exported by Help+Manual are downcased on export (this cannot be changed), I am afraid there is no solution but to make the calls with the correct case.

The correct standard syntax is actually index.html?topic.htm (note the ?, not the #). This will display the topic with the full TOC. If you call the topic only (topic.htm) and the skin is not too old, you will get the topic only, but there will be a link above the topic title that the user can click on to redisplay with the full TOC. This needs to be done this way because the automatic redisplay that used to be the default setting is interpreted by Google as an attempt to increase your ranking with double page views. Google then stops indexing your site.

[markusflow]

Sorry, if I skipped some information. We generate an offline HTML no server help with Premium Pack Version 4.3.0. So I think index.html#topic.htm is fine here, isn't it?

I wrote a shot Java Script that first catches the file name and if there are upper cases, converts them. All calls from the application works fine now (TOC is synchronised and the breadcrumb as well).

Code: Select all

<script>
function hasUpperCase(str) {
    return str !== str.toLowerCase();
}

var url = window.location.href;
var filename = url.substring(url.lastIndexOf('/')+1);
if (hasUpperCase(filename)){
	var newfilename = filename.toLowerCase();
	var newurl = url.replace(filename,"index.htm#"+newfilename)
	window.location.replace(newurl);
	}
</script>

[Tim Green]

Sorry, if I skipped some information. We generate an offline HTML no server help with Premium Pack Version 4.3.0. So I think index.html#topic.htm is fine here, isn't it?

The # and ? in the URL are two totally different things. If you are using standard Help+Manual WebHelp output with one of the standard skins, using the # character in front of the topic filename will not work. You need to use the standard index.html?topic.htm syntax if you want to get the proper result.

[markusflow]

I think we are fine here and my problem is resolved. Thank you, Tim.

Just for clarification: I am using a Premium Pack skin and when I locally open the index.html with a double click, the help generates the syntax index.html#topic.htm by its own. The # is nothing that I initiated.

[Tim Green]

Just for clarification: I am using a Premium Pack skin and when I locally open the index.html with a double click, the help generates the syntax index.html#topic.htm by its own. The # is nothing that I initiated.

That is a special case, where you are opening WebHelp using a V3, V4, or V5 Premium Pack skin without a web server. That is supported in these Premium Pack skins, but it is still not recommended except for very special cases, like local WebHelp on a Linux or Unix machine. In all other cases, use eWriter instead for local WebHelp. It packs WebHelp in a single file and provides a viewer that you or your users can install. Regular WebHelp should be on a web server, either on the Internet or on your local Intranet.