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: Suggestions for new tool option From:"Brierley, Sean" <Sean -at- Quodata -dot- Com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Mon, 4 Jun 2001 15:07:03 -0400
Hi:
Andrew, thanks for the info. To delve into this topic of graphics even
further, you mention Word stores all embedded graphics as binaries in a
special portion of the file, and that this leads to some issues with some
file types. Accepting that as true, does not importing by linking get around
that?
The Acrobat PostScript processes might be picky, but why do you think it
discriminate against GIFs? I recommend using ZIP compression, which is
loss-less. Thoughts?
You mention one of the reasons GIFs are troublesome is that they are limited
to 256 colors. I'm not sure why that makes them less reliable in Word. If
you use a consistent palette and recognize the limitation, that is, you are
not delivering color-accurate publications, does it really matter? Isn't
this just a limitation of the graphics format, rather than some kind of
compatibility problem. You can suffer similar color accuracy problems by
boosting an RGB screen capture to CMYK, or reducing the color depth of a
TIFF to 8-bit/256 colors.
As for JPEGs, this lossy format makes it ill-suited for screen captures but,
if you are including scanned photographs or the like in your document, is
JPEG not a reasonable format?
As for file size. Reducing the color in an image from CMYK or RGB to 256
colors will save a lot of disk space. Then, matching the resolution of the
image to the linescreen or resolution of your output will save even more.
That is, don't input a 1200-dpi 32-bit scan if you are outputting to the web
or a 600-dpi laser printer. Use an 8-bit, 120-dpi image or 24-bit,
96dpi-image instead.
I agree wholeheartedly with your suggestion of a graphics library. Of
course, if you import by linking, then you build this library anyway, right?
I'm not sure why linking does not work for you.
*** Deva(tm) Tools for Dreamweaver and Deva(tm) Search ***
Build Contents, Indexes, and Search for Web Sites and Help Systems
Available now at http://www.devahelp.com or info -at- devahelp -dot- com
Sponsored by Cub Lea, specialist in low-cost outsourced development
and documentation. Overload and time-sensitive jobs at exceptional
rates. Unique free gifts for all visitors to http://www.cublea.com
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.