Re: some different needs for single sourcing

[Craig Sanders <csanders -at- BEST -dot- COM>]

Hello, Chuck.

You seem to be facing an increasingly common problem: how to design and produce
docs that can easily be output as print or online.

I have been developing single-source solutions for the past seveal months using
WebWorks Publisher in conjunction with FrameMaker, and have found it to be the
only industrial strength tool available.

I was curious as to your remark that you had tried Publisher and that it did
not produce HTMLHelp. Publisher 4.0 can output HTML, HTMLHelp, WinHelp, and
JavaHelp. Additionally, there is a beta available now that can read several
foreign character sets, including Kanjii. You might want to have another look
at the product.

FrameMaker provides a strong complement to Publisher in that it is the tool of
choice for long complex documents, and easily produces top quality print docs.
By using the conditional text tags within FrameMaker, you can easily add
material that is for online output only, print only, and common. Then, using
Publisher, you can set up to output any combination of the above tags.

Even better, you can incorporate CSS files within your online doc set,
embedding the necessary code directly within a Publisher template. In fact, I
am in the middle of designing a template that does just that for a large
network equipment manufacturer, and the results I am getting are very good
indeed.

Hope this helps,
Craig Sanders

Chuck Martin wrote:

> This is a multi-part message in MIME format.
> --------------EA82FF1440E97F569231A4E4
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> I'm baaaaaaack!    :)
>
> I was looking through some recent posts on single sourcing and I have a
> question/issue that I did not see addressed, and I could use some input
> from others in the technical communication community.
>
> I am investigating tools for single sourcing. Here's the situation I am
> in:
>
> The group that I am in here produces documentation for application
> development tools. Several tools exists and are related, and perhaps
> could even be considered a suite. In the most recent release, a decision
> was made to go essentially online. The primary platform is Windows, with
> some sold on Unix. WinHelp 4.0 was used, with the projects running from
> more than 500 to several thousand topics. In addition, a number of
> common components were included in each product's Help system. The main
> Help authoring system was Word 95/RoboHelp 5.x. After the winHelp
> systems wer done, conversion using various types of scripts (Perl, I
> think) and brute force produced output for Unix.
>
> For the next release the goal is to move to HTML Help. But we also will
> need to produce printed copy (customers are demanding it), but for only
> a portion of the material: the reference stuff, not procedureal or
> context-sensitive. We will also need to produce HTML for web-based
> documentation and Acrobat, although I'm not sure if the Acrobat will be
> only what is actually published in print or the entire Help system.
>
> A number of people in my group are pushing for HTML authoring systems,
> such as HomeSite. There is a desire to perhaps work in RoboHTML. But I
> and my manager are very cognizant of the need to also produce printed
> output, and I'm concerned that once we convert all the Word/RoboHELP
> documents to HTML, that producing print documents will be an arduous
> task. Blue Sky's tools have not produced very good print output, and
> cannot output just a portion of a Help system to a print file.
>
> I have investigated a number of options so far to varying degrees. I
> looked at FrameMaker/WebWorks Publisher. This doesn't input Help
> systems, so the groudwork to rearchitect for this environment would be
> prohibitive. In addition, a lot of the same people who are pushing for
> native HTML athoring tools are pushing just as hard to not use
> print-based tools, such as Frame or Word.
>
> I tried looking at the latest Doc To Help 4, which is one of the few
> tools that supports JavaHelp. But that test bed system, working on Word
> 97, has so far failed because the embedded Word 95 macros that are part
> of RoboHELP and get converted to VBA don't all work. The bug prevents me
> from importing even one source file into the Word/Doc To help
> environment.
>
> Through recent posts on this list I found and downloaded AutoDoc and
> HTML2Frame. I have not yet had the opportunity to test these (today's
> tasks).
>
> A comment Eric made on the earlier single-source thread jarred me,
> saying something to the effect that going to HTML is a one-way process.
> that is the tack I have already been taking; going from raw HTML to any
> sort of other format seems problematic. I also want to work within a
> system that doens't need a lot of hacks. i see too many already, and
> it's just too many potential problems.
>
> For good or for bad, the top priority has to be HTML and HTML Help; they
> have to look the best.
>
> I also have to look toward the future. Word 2000 is supposed to provide
> seamless transitions between Word and HTML; what will that do for Help
> authoring? We will have to support JavaHelp. and we have to look at the
> potentials of XML and a potential universal, cross-platform Help
> specification that could be developed by the W3C in years to come.
>
> I saw some people mention proprietary, database-based tools. That may be
> an option, but what's the learning curve? From first impression, it kind
> of looks like that's what AutoDoc is, and they told me in email that
> support for HTNL Help is coming in a few months.
>
> Id appreciate feedback on the situation I'm in (remembering that we're
> starting from winHelp-coded RTF files) and some suggestions for a
> complete solution. I'd also appreciate feedback on some of the above
> tools, if anyone has any experience--good or bad--with them.
>
> Many, many, many thanks.
> --------------EA82FF1440E97F569231A4E4
> Content-Type: text/x-vcard; charset=us-ascii;
>  name="cwmartin.vcf"
> Content-Transfer-Encoding: 7bit
> Content-Description: Card for Chuck Martin
> Content-Disposition: attachment;
>  filename="cwmartin.vcf"
>
> begin:vcard
> n:Martin;Chuck
> x-mozilla-html:FALSE
> org:Oracle Developer
> version:2.1
> email;internet:cwmartin -at- us -dot- oracle -dot- com
> title:Principal Technical Writer
> x-mozilla-cpt:;0
> tel;work:650-633-6169
> fn:Chuck Martin
> end:vcard
>
> --------------EA82FF1440E97F569231A4E4--
>
> From ??? -at- ??? Sun Jan 00 00:00:00 0000==

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=