producing good HTML (was: Re: Frame -> HTML)

["Chuck" <writer -at- best -dot- com>]

I looked at that demo site. It had some interesting features. But I'm also
wondering why a few things look the way they go.

First, the fonts look *very* different between Netscape Navigator and
Internet Explorer. The fonts in IE 5 are *much* larger than in NN 4.7. Also,
the Index entries have soooo much vertical space between them. and the large
indents for both the TOC and Index squeeze the text in an already-tight
space.

I'm working on a contract where I'm asked to produce HTML files for a Help
system for a Java application. I suggested JavaHelp, but the additional
files that users would need to download to access the Help were deemed too
large to be useful. So I'm looking at other options.

The HTML output by RoboHELP 7 and Word 97 is badly formed HTML; pretty much
most of the structure tags are stripped out and replaced with CLASS
attributes in <P> tags, or simply <P> tags with <B> tags. Blue Sky blames it
on Word's HTML output.

The HTML output by RoboHTML is full or extraneous tags and attributes. Plus,
the external style sheet has duplicate styles with slighly different names.
Blue Sky says that they license the RoboHTML application and have no control
over the decisions made on how the HTML is created.

I took a quick look at the HTML output from Doc-To-Help and Word. I don't
rememebr all the details, but I saw a lot of extra stuff in the HTML code
that I didn't like.

I tried ForeHelp/ForeHTML. At first, I got a lot of extra stuff in the HTML,
so much that it double or tripled the size of each HTML file. But I found a
couple of options that eliminated the extraneous stuff, and now I'm getting
almost perfectly clean HTML: correct tags for the content with no extra
attrubutes or comments. (I will be trying a couple more tweaks to work on
one or two more issues.) The cross platform Help ehre requires 200-400K of
compressed files though because all the navigation is controlled through a
Java applet, and there's JavaScript as well.

A lot of people hav talked about the Frame/Webworks combination. I haven't
tried it. Is it better than the cross-platform solution by
ForeHelp/ForeHTML?

I don't have a lot of time to come up to speed on new tools; this is a
short-term project and I need to find the cleanest, smallest HTML output
with the minimal amount of work. I need something that will provide
navigation too; I don't think I have the time to code navigational features
by hand (which I could do in a direct HTML tool such as Dreamweaver or
HomeSite). That's why the cross-platform HTML systems developed by Blue Sky,
ForeFront, and so on are appealing; they provide the integrated navigational
funtions, but at a cost of extra files.

Right now, though, I'm leaning toward ForeHTML. We've got a copy of RoboHELP
2000 coming and I'll run it through its paces with Word 2000. Unless a
*very* compelling argument can be made for the Frame/Webworks combination
for authoring and producing good HTML with cross platform navigation, I
don't think the budget exists to also but the latest versions of the 2
tools.

Thoughts?

Chuck Martin
writer -at- best -dot- com

Mark Dempsey <mxd2 -at- osi -dot- com> wrote in message news:25624 -at- techwr-l -dot-  -dot-  -dot- 
<snip>
> We're also experimenting with HTML (produced by Quadralay's Webworks,
> *not* Frame alone). See:
> http://www.geocities.com/CapitolHill/Senate/1059/helpfrm.html for an
> example of cross-platform/cross-browser HTML produced from Frame by
> webworks. Most of the control you seek for HTML conversion is not
> available from Frame. You must use Webworks.
>
> The basic problems with HTML are that, as good as Webworks output is
> (and it's pretty good), there's at least another edit cycle to check the
> output to see it's not garbled somehow. Also, you must mark certain
> things as "print only" with conditional text (e.g. the "Conventions in
> this manual" section that explains font use, or graphics you do not want
> to see in the HTML output). Webworks will exclude the conditional text
> settings you configure. Maintaining this difference between print and
> online is not part of the pdf output, but must be part of the HTML doc
> production.