Thanks, Brian, but essentially that thread just confirms what
I already figured out. What I'd like to know is whose limitation it
is, why it's there, and whether there is any plan to fix it. There
is no such limitation (or it's considerably less restrictive) when
generating Webhelp from the same project. To me, this makes chm
output useless.
I'm documenting a fairly complex system, and as such, the
nesting of topics is a necessary evil. It puts too much onus on the
writer to have to artificially limit the names of folders and
topics so that they fit into an arbitrarily small string length,
especially when there is no warning that the limit has been
exceeded. I have generally 2 or 3, though in a few places up to 5,
levels of nesting in the help project, and my folder and file names
are descriptive without being ridiculously long. The example that I
gave before is typical. That file name was originally
Market_Properties_Overview.htm. I could arguably call it just
Overview, as the rest of the name is somewhat implied by the
nesting level, but if the file were to get moved, it becomes harder
to be sure what it's an overview of.
We're either going to have to switch to outputting Webhelp,
or consider switching products, as a competing product did not
exhibit the same behavior when producing a chm file from the same
project. Any thoughts about the benefits of Webhelp vs. HTML Help
would be of interest. We don't currently have a need to make the
help accessible over the internet, but the Webhelp can be run just
locally.