This content has been marked as final. Show 2 replies
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.