Help to RTF can extract images, RTF source code, .HPJ compiler configuration files, baggage” files and all other data contained in a compiled helpfile, resulting in a fully recompilable Help project from virtually any given .HLP file which is not protected by encryption or anti-decompile technology (Less than half of one percent of all helpfiles are decompile-protected.)

But while its recompile accuracy is usually a full 100 percent when compared to the original compiled file, be aware that the source files generated by Help to RTF will not and can never be identical to the source code originally used to create the .HLP file. Some types of information simply are not preserved when a helpfile or Multimedia Viewer title is compiled, and whatever isnt included in a compiled file cannot possibly be extracted by a decompiler. No decompiler could ever fully reproduce the authors source files exactly as they appeared prior to compiling.

In most cases this will not be a problem. When Help to RTF decompiles a helpfile, none of the most critical data is omitted. Images, baggage, compiler information, keywords, text and formatting information is all preserved in the decompiled files. But its important to know what cant be reproduced by Help to RTF.

Firstly, styles used by the RTF generation software are not stored within the compiled .HLP itself, so modification of RTF source documents in a word processor or authoring tool will generally require a little extra effort.

Secondly, topic ID strings (#” footnote entries) and jump/popup context strings (hidden link text) in the source files are not preserved by the compiler. Instead they are converted to unique values referred to as hash codes”. Hash codes are text representations of 32 bit data values that look to the average person like random series of characters. These cryptic-looking strings of text usually represent longer strings, but conversion of the compiled, converted strings back to text cannot be done accurately since the same hash code could represent more than one possible string of characters. The best any program could do is make educated guesses about the original string, and even the best possible code for doing this is unlikely to produce better than a 25 to 35 percent hit” ratio for any given set of helpfiles.

If Help to RTF cannot deduce a unique topic ID string to correspond with a given hash code, it will make a best-guess attempt to recreate a string that has the same corresponding hash code. However, the resulting text string may look very different from the string originally created by the author.

This apparent alteration of context strings in the compile/decompile process should have no effect on a recompiled helpfile. After recompiling a file with HC31.EXE or HCRTF.EXE, the resulting jumps and popups will be identical, even when there is an ”interfile jump” to or from another help file.

Topic ID strings embedded in .SHG files (Segmented Hypergraphics, a Help- and Viewer-specific graphics format) are immune to this type of data loss. Topic ID strings stored in .SHG files are preserved in a compiled .HLP and Help to RTF can make use of these ID strings where they are available, attempting to match topic IDs in the RTF source with topic IDs in the .SHGs.

Help to RTF will optionally split large .HLP files into several RTF files. In some cases large helpfiles produce massive RTF source documents which might otherwise be impossible to load into word processors on average home PCs.

Note once again that helpfiles are usually protected by copyright laws. Under no circumstance does Herd Software Development endorse or encourage violation of copyright through indiscriminate decompilation of copyright-protected Help and Viewer files. Modification of a decompiled helpfile without the permission of the copyright holder may constitute such a violation.