Limited space, but want HTML features

[cherie_w]

Hi RoboGurus and RoboWizard:

I'm placing the generated project files on an appliance with limited space. I've convinced my client to go from Word PDF to Word WebHelp for better modularization and to have a more professional interface with the GUI embedded on the appliance.
One PDF was nearing 3M, which was starting to become a concern for the developer. The WebHelp dir is right at 3M, which is almost twice as big as its PDF complement (his enthusiasm diminished when he realized it).
I saw the discussion on the whdata (etc.) files and how they're not to be elimiated if you want the interface to work properly. (All three of the wh directories equal over 1M.)
Most image files are close to 1K, and there aren't many, so I don't think those are the problem.

PLEASE!
How can I reduce the output file size and assage the fear and dread of incorporating the help system my developer has?

[Guest]

Is there any reason that you can't simply create a HTML .CHM file and create map ids for the developers to use to access a specific topic from within the application?

Brian

[cherie_w]

The CHM file would be smaller, but we're working with javascript.
I've used CHM files with C apps before, but will it work in this environment?
I found real reluctance when talking about a mapping file.
Right now, I just supply a table with GUI page names mapped to the RH HTML file names.
Your help is appreciated.

[MergeThis]

Your developer should be made aware that the online help will generally grow in relation to the complexity of the software application (our financial product's merged Webhelp weighs in at 125 MB).

So, if he's willing to remove some features...well, your help might be reduced accordingly.


Good luck,
Leon

[Guest]

Ok, .CHM is a no go.

1. You are producing WebHelp. Are you using RH for Word? If so, why?
2. If you are using RH wysiwyg editor, have you imported Word files? If so, check in True code. You will find a plethera of redundant codes. Removing these will help reduce the size of your output.
3. The images. Are the originals in .gif format? Although robohelp will change them to gifs when you publish, it is best to have the originals as gif.

Let us know exactly what you are using in RH, and how you using it, but I can't see that a major reduction in size will be possible.

As Leon has stated, the size of your project is quite small, and will most probably grow.

Why is there such a restriction on the size? Drives are relatively cheap these days.

Best of luck with this.

Brian

[Roger_N]

cherie -

There are a couple things you could do. Being that your are installing these files on an appliance with limited space, some options are limited. Ideally, the help content has been written with clear, concise language with a minimum of extraneous material. You can ask yourself, is all that content really necessary?

If, for instance, you have a good Index, you might eliminate the Search function. This might reduce your help system to a third of it's original size. My test files dropped from 33 to 13 Mbs.

Using RoboHtml instead of Robohelp for Word should create cleaner markup, if that is an option. Otherwise, DreamWeaver or TidyHtml will clean up a lot of unnecessary tags.

Lastly, generating the content files only to a PDF should provide some compression options that are not available in WebHelp alone.

[cherie_w]

I'm sorry if I gave the impression I was using RoboWord. I'm using RoboHTML. Word is used as the authoring tool, for reviews and version tracking, and modularization. A PDF is still generated and available online. But yes, these are imported Word files.

One of the things the client liked was the search feature, even though there's a comprehensive index. I thought it better that the GUI have a context-sensitive help system. They wanted to keep the manual and help in sync, and hence the modules. This is why I recommended HTML help.

The client has been delivering the manual as a PDF, available from the browser-based GUI. The PDFs were also nearing 3M, which was over the DEV ceiling. There isn't a drive on the appliance, just a bit of memory, so space is critical.

I've built other systems (none as gigantic as yours, Leon), and even the larger systems have been ~10M. I thought that this small a system--really only a third of the page count of the last 5M system--would have a corresponding size reduction. Apparently there are a lot of support files that take up the first 1M.

There are a few gifs and some jpgs, but not many, and none are over 7K. Also, I am using DHTML features and glossary hotspots.

The CHM file had my client all excited, but with Linux and Mac, and the zilla-flavored browsers to support, it's really not the solution.

You've got me rethinking the project, Roger--and I'll run Dreamweaver or HTMLTidy to check code (and what to do with all those kadovs?!?). I may also just include the GUI-critical content in the help, and include a link to the PDF, where theory and specs and the like are kept.

It was a nice dream, while it lasted.

Thanks so much!