RE: Linking to graphics: why, why not?

Subject: RE: Linking to graphics: why, why not?
From: Paul Hanson <PHanson -at- Quintrex -dot- com>
To: TECHWR-L <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 19 Sep 2000 11:16:15 -0500

Well, well, well . . . I am one of the unwashed spirits. I don't
trust linking. I have had documents linked to another file, either the
referenced file is moved or not copied along with the original . . .
lots of nitpicky details that, I guess, I resolved by saving the graphic
within. I haven't had problems with large document file sizes, though
I've had slow save times. I am the only TW here so point 2 below doesn't
really apply to me, and I have an issue with item 3, that I detail
below.
All that said, though, I'm seeing the overwhelming support for
referencing graphics, instead of including them, and I'm considering
changing my ways. The following 'details' come to mind. How do you
handle the following:
1) How do you know what graphic is used multiple times?
2) Do you keep a list of documents that refer to a single graphic?
3) Do you use some sort of database, with a record for each document and
the file names of the graphics that are used in it?
4) Do you use a directory structure, or just put all graphics in all
documentation in one (gigantic) folder?
5) What sort of backup schedule do you use for your graphics folder?
The other issue I need to resolve, and ties in with point 3
below, is situations like this example:
A lot of our system depends on something called an "Item Code" being set
up in a program called "Item Code A/C/D/D." The existing screen captures
in our documentation has specific data keyed in as it applies to the
type of Item Code being set up. Therefore, it's impossible to use only
one capture of the Item Code window. I end up with multiple Item Code
windows in multiple documents and when a new field is added to the
window, I may have 10-100 (I don't have a count on how many documents
refer to Item Codes) different screen captures to re-capture, with the
same data, to reflect that there is a new field. I think this because I
want the capture to match the current software.
I have considered listing the fields on the Item Code window
that are required and not using any graphic. Is that a reasonable
strategy? Probably every other project (5 out of 10) that we do around
here references Item Codes in some way. It's a 'popular' program, I
guess, because everyone is always changing it.
And as my signature says: Ideas, suggestions, comments, solutions, etc.
appreciated.

Paul Hanson
Quintrex Data Systems
http://www.quintrex.com



> -----Original Message-----
> From: Michele Marques [SMTP:marquesm -at- autros -dot- com]
> Sent: Tuesday, September 19, 2000 10:58 AM
> To: TECHWR-L
> Subject: RE: Linking to graphics: why, why not?
>
> Why should you link to graphics rather than embed them?
> (1) As mentioned before, size of the document. The large size can
> result in:
> - lengthy times to open and save documents
> - additional opportunities for file corruption
> (2)If images are separate files, one person can update images while
> another
> person is editing the document.
> (3) If the same image is used in multiple places, it only exists once
> with
> multiple links. This saves on filespace, and, more importantly, means
> that
> updating the image once updates it in all locations.
>




Previous by Author: SOLUTION: Converting text into tables
Next by Author: RE: Writing functional specifications
Previous by Thread: RE: Linking to graphics: why, why not?
Next by Thread: RE: Linking to graphics: why, why not?


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads