#### 18.14.3 Putting up with a binary index for merged CHM files

When you merge CHM files, you are totally dependent on the Help Compiler to sort the index; sort strings do not help, and DITA2Go cannot change that. This is true regardless of how you produce the CHM. Creating your own .hhk file with the order you want does not work, because the compiler ignores that order when creating the binary sort. The only thing that could affect the binary sort order is the sort code in the Windows OS on the machine where the compiler is run.

For example, to get a binary index sorted for Japanese HTML Help, you would have to compile on a native Japanese system, not just on an English system with a Japanese IME running. In that case, you have handed over control of sort order to Windows; you get what it gives you, and that is that. On the other hand, so does everyone else, so users should be used to it.

The other choice is to build the Help as a single, non-merged project, with variations for each use case if some modules are present and others excluded for specific audiences. That may be the only answer, if you do not like the Windows sort order. With five modules, you would have 120 possible combinations, but perhaps not all of them are really used. And even if they are, disk space is cheap, and you could install just the one needed on a given user’s system.

Previous Topic: 18.14.2 Synchronizing TOC references to slave CHM files

Next Topic: 18.14.4 Merging CHM files

Parent Topic: 18.14 Mapping and merging CHM files

Sibling Topics:

18.14.1 Interlinking multiple CHM files

18.14.2 Synchronizing TOC references to slave CHM files

18.14.4 Merging CHM files

18.14.5 Comparing HHW settings for stand-alone vs. merged CHMs

Table of Contents • Index