RE: Suggestions for new tool options

[Chris Gooch <Chris -at- lightwork -dot- co -dot- uk>]

Keeping on the subject of embedding graphics, and why linking
them (may) not be a good idea;

As an ex-programmer I am prone to think of "source data/files" and
"object data/files". A compiler gets you from one to the other.
The first is used for building a program or a document/book, the
latter is used for distributing the program or document/book.

This is clear to me as I use LaTex to write in, which contains pointers
to images (ie. links). However when I "build" a finished book in postscript
or PDF it then embeds (copies) of the images directly in the finished
file.

If you use Word, and all you ever send to anyone else is a postscript
or PDF file which embeds everything, then you are in the same position.
Anyone you send the PDF or PS file to can see everything no problem.
(In this case Word is the source format and PDF or PS is the object format).

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).

Keeping the "source" and "object" distinction in mind makes a lot of
things clearer IMHO.

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. 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,
but tailor them to the end-document each time you use (embed) them.

HTH

Christopher Gooch, Technical Author,
LightWork Design Ltd., Sheffield, England. 
chris -at- lightwork -dot- co -dot- uk    www.lightwork.com




^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

*** 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.