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.
Paula Reynolds writes:
> Where do you save scanned images? I used about
> a half-dozen images in a very short (7 pages) set of instructions, and
> the file is...get this...10 meg. It's enormous!
10 megs for 6 photos is about normal. When estimating document sizes, we figure
about 1 meg per photo (B&W). That means a manual with 100 photos is going to
take about 100 megs. We scan and store our photos at 300 dpi, 8 bit grayscale;
each square inch of photo requires 90K bytes (K=1000). Therefore:
> -- I love how the scanned images look, and I swore "as God is my witness,
> I'll never cut and paste again..." Perhaps I was a tad too hasty?
No, you are not too hasty but you do need lots of memory, both RAM and disk.
Fortunately, the cost of both has dramatically fallen over the past few years.
Also, the newer medium priced laser printers (we have an HP 4+) print B&W photos
"good enough" for most technical documentation. Therefore, photos will be
increasingly used and stored electronically.
> Any advice on how you save scanned images?
We use a 1.1 gigabyte drive for active files and SyQuest cartridges for
completed documents. FWIW, a single archive for a set of three manuals we
recently did required 360 megabytes. The customer refused our offer to deliver
on 1000 floppy disks.
Data compression is a reasonable way to save disk space, however, be aware of
the difference between lossless and lossy compression schemes. A lossless
scheme (such as StuffIt) will completely reconstruct the original data upon
retrieveal. A lossy scheme (such as JPEG) throws away part of the grayscale
dynamic range to achieve a smaller file size. This loss may be acceptable for
you work; run some tests and find out.
Scanned graphics are another question. First, scanned graphics such a line art
should never be stored in gray scale. The data should be scanned in or
converted to single bit per pixel format (sometimes called Bit Mapped Graphics).
Otherwise you are using a full 8 bit byte where a single bit will do. For
single bit per pixel data, divide the B&W values in the above table by 8.
Second, consider converting scanned graphic images to graphic objects (also
referred to as vectors). One way to do this is to scan the image, load it into
a Draw application (Adobe Illustrator, ClarisDraw, CorelDraw, etc.) and trace
over it. Then throw the scanned image away. The vector drawing is more
precise, easier to edit, and probably takes less disk space. The main
disadvantave to vector drawings is that they are not as transportable between
applications and computer types (PC's, Mac's and UNIX).
If hand tracing of a scanned image is not acceptabe, consider using one of the
autotrace packages such as Adobe Streamline. It automatically converts scanned
images to vector drawings. I believe CorelDraw has an autotrace function build
into the application. In my experience, Adobe Streamline, and I suspect most
autotrace packages, do a fair to good job (not geat). For example, Streamline
does not recognize a circle as a circle, but rather a series of curved lines.
If you are finicky about your work, expect to do a bit of retouch to the
autotrace results.
Good luck
Cordell
-----------------------
Joyce F. Woods & J.Cordell Woods / Consultants
Cactus Software & Communications, Inc.
3151 Main Street NE; Blaine MN 55449-6112
voice 612/757-6916 fax 612/757-4515 email jfwoods -at- maroon -dot- tc -dot- umn -dot- edu
