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.
I have purchased RoboHelp for a couple other companies -- I was an early
customer. I'm evaluating RoboHelp Office 9.2 and I think my comments could
be valuable to eHelp.
My analysis below reduces to a request for documentation of the following:
o What features are and are not supported when producing .chm from .doc
using only the RoboHelp Classic environment, without migrating to the
RoboHTML environment?
o How should I format the .doc in order to control the .htm table tagging
that results -- including cellspacing, cellpadding, border, background, and
column width or auto-width?
o How can I prevent my .css file from being overwritten each time I
generate the .chm from Classic?
o Generally, using only RoboHelp Classic, how can I control the .chm
creation by my .doc formatting and project settings and conversion settings?
I can post these questions separately, but I also wanted to build up
awareness of the overall scenario that gets the least attention of all, yet
is powerful and more popular than eHelp seems to assume: generating .chm
from .doc in RoboHelp Classic.
eHelp seems to provide no documentation about this "middle way" of using
RoboHelp Office. What are the considerations, issues, limitations, gotchas,
workarounds, problems, FAQs, advantages -- for using WinHelp-style Word
longdocs to directly produce a .chm.
eHelp evidently assumes people either use RoboHelp for WinHelp to produce
.hlp, or use RoboHelp for HTML to produce a .chm, or use RoboHelp Explorer:
File: Generate: Microsoft HTML Help 1 time, to "convert" a WinHelp project
to an HTML Help project -- that is, to a RoboHelp for HTML project.
But I wonder if eHelp really knows how the usage audience breaks out. I
think there are a lot of people who are using RoboHelp the "wrong" way, like
I do -- using RoboHelp Explorer each day to directly produce decent .chm
from WinHelp-tagged .doc files.
I never touch RoboHelp for HTML environment this way. I get the impression
from talking to eHelp and from the lack of docs regarding this path, that
eHelp is largely unaware of this usage path. Everything I can find talks
about "converting" as though I'm eager to manually maintain my docs within
the RoboHelp for HTML environment. But I want to stay strictly within
RoboHelp for WinHelp, and choose .chm as the mere output viewer type that I
happen to be targeting.
I the eHelp discussion area, I'm seeing a lot of references to problems
people run into when trying to use this .doc->.chm daily build process. One
posting says there is no documentation for this process. From the RoboHelp
Classic documentation:
"Microsoft HTML Help -- This format is developed by Microsoft to display
Help in Windows applications. Microsoft HTML Help is based on Hypertext
Markup Language (HTML) files. You can run Microsoft HTML Help on Windows 95,
98, NT 4.0, and 2000 using Internet Explorer 4.x or later. Use the Microsoft
HTML Help format to create application Help, stand-alone Help, online
policies and procedures, and more, for end users that run Windows and
Internet Explorer.
Use RoboHELP HTML to generate Microsoft HTML Help."
The last sentence is really a gross error.
See, eHelp keeps pushing customers away from the .doc-->.chm process that's
all within RoboHelp Classic including RoboHelp Explorer, and toward RoboHelp
HTML. I see no technical reason why I should have to pull the entire
project over into RoboHelp HTML, when RoboHelp Classic appears to more or
less support a standard daily .doc-->.chm process.
Now, I do have about 5 specific questions about the .doc-->.chm daily build
process, but my more general concern is that there is no voice for
RoboHelp'ers who do the .doc-->.chm process -- the users are divided into
"Classic" vs. "HTML" environments, with the first assumed to be creating
WinHelp 2000, and the latter creating HTML Help.
But what about focused official documentation and a place for people who use
RoboHelp Classic and choose to use .chm as merely just another output format
-- *without* moving the whole project every day over into RoboHelp for HTML?
Such users need to established some shared understandings; otherwise it
seems like eHelp is *unable* to understand what I'm trying to do. The last
thing in the world I want is to migrate my project into RoboHelp for HTML,
but all the official docs either assume Classic-for-.hlp or
RoboHTML-for-.chm.
The same is true of the 3rd-party books -- they always assume you are either
using Classic to produce .hlp or RoboHTML to produce .chm. What I'd pay for
is a book about how to use Classic to produce a .chm. Can it be done? Can
you do merged .chm's this way, for example? For example, the .css keeps
being forcefully overwritten in this procedure, even when I make it a
read-only file. Where is this doc'd with specific procedures? There simply
is no chapter in the RoboHelp docs about this whole procedure and related
considerations.
When you select RoboHelp Explorer: File: Generate: Microsoft HTML Help, for
each dialog box, there is a Help button with a secondary-window Help topic
in WinHelp format. It's not much documentation and it doesn't discuss
problems and workarounds. Such topics are not listed in the table of
contents. I was, however, able to do a Search and display each topic in the
primary window.
Generate dialog
Define Build Tag Expression dialog
Folders dialog
Formatting dialog
Features dialog
Options dialog (see the one for HTML Help)
Advanced: Tri-pane options
Advanced: TOC options
Advanced: Custom Button options
I found some additional related topics comparing .chm to .hlp, such as
"Using Single Source". There are several topics in the book Comparing
WinHelp to Microsoft HTML Help, but no real procedural documentation. For
example, in the topic "Topic formatting comparison", it says "you can change
the formatting" -- "HH uses .css" -- but it doesn't tell what procedure
enables this when using Classic to create a .chm.
The not-quite-complete documentation for the .doc-->.chm approach to
RoboHelp Classic is partly due to industry-standard weak TOC design
reflecting the idea that it's beneficial to omit many topics from the online
TOC. This set of 9 hidden topics about the .doc-->.chm approach in RoboHelp
Classic and should be visible in the TOC. If it were visible, it would be
more obvious to the authors of the RoboHelp documentation that conceptual
and procedural topics, and QA testing as well, are needed to go along with
these dialog-box Help topics.
A good example of how the RoboHelp Classic docs don't really tell how to use
RoboHelp Classic to output a .chm: Table formatting is not really doc'd for
how to control the HTML table tagging based on the .doc formatting.
Because my customized .css file keeps getting nuked, but the docs don't
mention this major problem, it seems like eHelp has not really tested
controlling .chm creation using Classic, or any limitations and bugs haven't
really been fixed -- instead, the docs just say "convert your project to the
RoboHTML environment" -- overlooking that you may have very good reasons not
to do that. I want long .doc sources with 1-click building of a .chm that
has proper features.
I'm getting really mixed messages from eHelp whether the .doc to .chm path
is fully supported. I think many people would like to stay in the Classic
environment, with long .doc source files, and controllably build a .chm from
there -- *without* converting the entire project over to RoboHTML.
As the docs stand now, I *think* Classic is close to being able to do a
good, controllable job of creating .chm from .doc -- but I can't tell for
sure. There are many features I haven't tried to output as .chm. So far,
as an inexperienced 9.2 demo user, the things I consider *most* basic have
not come through:
o Retaining .css customization
o Automatic creation of a hierarchical TOC, with every node a live link,
based on the .doc heading levels, with no manual repair required.
o Outputting tables that have auto-width for columns.
Planning to attend IPCC 01, October 24-27 in Santa Fe? Sign up by
October 3 and get a substantial discount! Program information,
online registration, and more on http://ieeepcs.org/2001/
+++ Miramo -- Database/XML publishing automation. See us at +++
+++ Seybold SFO, Sept. 25-27, in the Adobe Partners Pavilion +++
+++ More info: http://www.axialinfo.comhttp://www.miramo.com +++
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
