TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
| There are situations where WinHelp just runs out of gas.
I won't argue with that. If WinHelp doesn't support functionality you need
for your Help system, you should certainly investigate alternatives, of
which HTML Help is one
| We are currently examining this problem as we typeset a lot of math and
| equations in our documents. These go into WinHelp as graphics.
| WinHelp files with a lot of graphics are prone to corruption.
I will argue with this. I'm not sure what you mean by "a lot of graphics,"
but we routinely produce WinHelp systems with thousands of graphics and have
never seen any corruption in a WinHelp file as a result. Perhaps you meant
that "Word documents with a lot of graphics are prone to corruption," and
with that I would entirely agree. Microsoft Word is the weakest link in any
major WinHelp production effort. (We don't use Word at all for the
aforementioned gigantic projects.)
| And, even when
| the problem isn't a corrupt graphics file, it can mask real help build
| problems. HTML help doesn't have the same problem.
Again, this is not a WinHelp problem but rather a tool problem (most likely