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 options From:"Brierley, Sean" <Sean -at- Quodata -dot- Com> To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Tue, 5 Jun 2001 10:07:58 -0400
Hallo:
> -----Original Message-----
> From: Chris Gooch [SMTP:Chris -at- lightwork -dot- co -dot- uk]
>
> If on the other hand (as many do) you use Word as *both* source and
> object format (ie. someone else is going to look at the Word doc),
> then you will encounter less headaches if you do as Andrew suggests
> and embed the images *in the version which you are going to use
> as the object version*. You may, or may not, continue to use linking
> in the source version (I can see that often there would little to be
> gained
> by maintaining the different source version).
>
This is exactly why your workflow and tool has to be decided *after* you
figure out what your deliverables are. You could, of course, ZIP the files
so that they unzip linked graphics to a correct location. You could decide
you don't want to share application source files (as I do, I ship PDF for
review and everything else). However, sharing DOC files is common practice.
> I also agree with Andrew about pre-formatting the images before
> including them in your doc --- I spend a lot of time in PSP or similar
> getting images that are the right size, aspect ratio, resolution, don't
> use colour information if it isn't needed, etc.
>
I deal mainly in screen captures. My workflow permits me to capture,
resample, and name my graphics perfectly to my satisfaction automatically,
without fussing around in a bitmap editor. As for your color comment,
remember, for display, color is free. It only costs in print if you are
outputting to a color printer and then, only really if color accuracy is
important. (If it is, the price will be high). Consider, too, that 8-bit
(256) color bitmaps are no larger than greyscale ones, which are also 8-bit.
> If you just link images
> you may not think about this, and then think embedding *must be*
> a bad idea 'cos the file size will be huge. It needn't be. Once again,
> the distinction between "source" image and "object" image is
> useful ---- keep a library of sources at the highest quality / res poss,
>
Highest res possible is a bad idea from the standpoint of wasting storage.
If you capture a screen, then 96dpi is fine cos that's the res of the
source. If it's a photograph, anticipate the linescreen or resolution of the
highest-res output device, but certainly you have to ask yourself if keeping
the image at more than 150 dpi is worth it.
> but tailor them to the end-document each time you use (embed) them.
>
> HTH
>
Cheers,
*** 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.
