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.
Subject:Re: graphics in Help files From:John Russell <johnr -at- BRS -dot- COM> Date:Tue, 26 Jul 1994 09:27:04 EDT
I'm posting this response to the list because I lost Anne's return address.
Sorry.
> I would assume that they're not bigger than a screen, (?) but larger than
> however you've sized your Help window.
Even small bitmaps can be pretty large.
> Finally, one trick for reducing the size of a bitmap: import it into the
> Shed editor (the editor to make hypergraphics) and save it as a .SHG
> (hypergraphic) file. The resulting file is quite a bit smaller than
> a bitmap.
This is assuming she is using Robohelp. Actually, a "shed" graphic is
a type of Windows metafile. You can convert any bitmap into a Windows
metafile if you have a conversion utility. Robohelp's shed graphics are
metafiles designed to handle hotspots for linking.
Are you using a help project package such as Robohelp or Doc-to-Help or the
like? The latest version of Robohelp converts bitmaps into a type of Windows
metafile, which are *significantly* smaller than bitmaps. I would
imagine you could convert your bitmaps into metafiles and that would
save you some space. How about a conversion utility, do you have one of
those? (Such as Hijaak for Windows, or the like...)
I've found that the help files I've created were better off broken
into smaller "subdocuments" (not "subdocument" like Word means, but just
other smaller documents). AND, by putting the bitmaps into a subdirectory
and not actually inserting them into the document helps, also. You can then
do a bitmap by reference so that they compile into the help file ok. (The
only problem with this method is that you have to compile and run the .hlp
file in order to see what your graphics look like on screen, where they
are positioned, etc...
>I have a large number of large documents to update and need to be able to
update
>one (or more master documents) and have that update the rest of the documents
>automatically with the changes. Is Word 6.0 for Windows suitable for large
>document creation and updating? Does anybody have any other suggestions for
>other packages? Thanks.
We have a similar problem in our department. We've considered FrameMaker
because it has an ability called "conditional text", which allows you to
determine what text appears in what printed version of your document. It
seems to be ideal for brochures and such, and certainly capable for long
documents, but we're not sure how exactly we'd apply it to our situation--
change in document A indicates changes in documents B and C, like your
situation. (We've also noted that Word has a hard time with long documents.)
I don't know of any other program, yet, that does what you are saying, but
I'm not familiar with Aldus Pagemaker, Quark Express, etc.
Don't know if this helps, but good luck.
--
kjr
johnr -at- lurch -dot- brs -dot- com
--------------------------------------------------------------------------
|/ K. John Russell \||/ \|
| Dataware Technologies, Inc. || Pity this poor monster man unkind |
| 5 Computer Drive South || not. |
| Albany, New York 12205 || - e.e.cummings |
|\ (518) 435-4025 /||\ /|
--------------------------------------------------------------------------