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.
Scott Turner notes, that in moving to HTML: <<You are about to forgo
control over the appearance of the text, and exact placement of
graphics. In fact, you lose all presentation control in moving to
HTML.>>
Many good points, particularly if you use only basic HTML, but several
points require some clarification to provide some nuance.
You can get around typographic and positioning problems without much
difficulty. Simple use of CSS lets you get around the typographic
problems, at least to some extent, though you may have to do a bit of
juggling to provide different style sheets for each browser, since they
don't all interprest CSS the same way. Arguably, the lack of control
over typography is a good thing, since it lets the use choose the font
that is most effective for them: with CSS, you can define your
preferred fonts, but users can override those controls in some
browsers.
As for graphics, you can accomplish fairly remarkable things about
positioning using tables with a little thought and experimentation.
Where the utmost in integration of text and graphics is necessary, it's
fairly easy to create the resulting composite graphic in a graphics
program, then save it in the appropriate graphics format. The key here
is to make the effort to analyze each situation to determine whether
the graphic and text should be allowed to float, or whether they should
be constrained and locked into position. Different situations call for
different solutions.
<<You also lose any security you may have used in PDF files.>>
Security is vastly overrated, particularly in the context of
documentation. The only people who could have any possible interest in
our documentation are the people who have purchased the products it
describes. And our competitors, I suppose, but that's what copyright is
for. If users decide to modify our HTML files, well that's no different
from them taking a ruler and pen and putting lines through printed
manuals, then writing their own instructions over top.
PDF security is also highly overrated; there are plenty of password
crackers out there (do a Google), at least for older versions of
Acrobat, and once you have a high-resolution PDF available on the
screen, any competent OCR program should be able to turn it quickly
into editable text. Indeed, there are programs that work directly from
PDF, without all that tedious scanning.
<<Depending on the tool you use to create your HTML files you may find
considerable bloating of the file with extraneous code (e.g. Microsoft
Word stuffs enormous amounts of excess, useless code into HTML produced
from it).>>
This is certainly true, particularly for older versions of Word. But
there are solutions. Dreamweaver does a decent job of cleaning up
Word's HTML, Word itself has a much-improved HTML export filter in
recent versions, and you can even write a Word macro to search for and
replace or eliminate the most common HTML problems that Word produces.
(In effect, you save the file as HTML, open it, run the macro, then
save it again _as a text file_ instead of "save as HTML".)
WebWorks ePublisher Pro for Word features support for every major Help
format plus PDF, HTML and more. Flexible, precise, and efficient content
delivery. Try it today!. http://www.webworks.com/techwr-l
Doc-To-Help includes a one-click RoboHelp project converter. It's that easy. Watch the demo at http://www.componentone.com/TECHWRL/DocToHelp2005
