RE: Linking to graphics: why, why not?

Subject: RE: Linking to graphics: why, why not?
From: "Brierley, Sean" <Sean -at- Quodata -dot- Com>
To: "'techwr-l -at- lists -dot- raycomm -dot- com'" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 19 Sep 2000 12:46:05 -0400


> -----Original Message-----
> From: Paul Hanson [SMTP:PHanson -at- Quintrex -dot- com]
I link everything. Period (full stop, even). I keep everything I link in
sub-folders in the same directory as my main document so the path remains
clear and defined and I don't have to worry much about relative versus
absolute path issues.

> 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 . . .
You only need to sort out an organizational structure and stick to it. I
have a graphics subdirectory in my main document directory for
imported-by-reference graphics. Not a problem in any software, Word,
FrameMaker, Ventura, etc., all handle things correctly.

> 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 *used* to have horrible problems with MS Word and file sizes . . . I trust
these have been fixed but I have not been back to check. Oh, and save times,
autosave, etc., in Word were horrible, too.


> The following 'details' come to mind. How do you
> handle the following:
> 1) How do you know what graphic is used multiple times?
In some software, you can create a list of graphics automatically. In
others, you can print out a copy of the book or PDF it and note the
filenames manually. Admittedly, managing this is extra overhead.

> 2) Do you keep a list of documents that refer to a single
> graphic?
Aha. While you can use a graphic in more than one document, I prefer not to.
I like to keep all files referenced by a given project downstream,
directorywise, of the main book or project. I dislike going up and over and
using some absolute path . . .. Thus, if one project has a graphic that I
want to reuse in another project, I copy the graphic (whilst keeping the
same name).

> 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?
You could. I don't. If there were more than two, heck, more than eight or so
writers here, I would invest in that. However, we are not so numerous nor
prolific as to require that kind of aid. I can see how it makes sense for
some, though.

> 4) Do you use a directory structure, or just put all
> graphics in all
> documentation in one (gigantic) folder?
I use a directory structure, such that all graphics are in a graphics
subdirectory. I might include another subdirectory for OLE and documents
other than graphics that I import by reference.

> 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 would do the following, given my limited resources here:

> **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.
I'm sure I don't fully understand the item code thing, but have you given
any thought to making it its own document or chapter, so you can eliminate
some of the overhead and have all your frequent updates in one place?

> And as my signature says: Ideas, suggestions, comments,
> solutions, etc.
> appreciated.
> Paul Hanson
> Quintrex Data Systems
Best regards,

sean -at- quodata -dot- com

Previous by Author: RE: QUERY/RANT: Little Word/Acrobrat idiosyncracy... or three
Next by Author: RE: need to compile a wish list
Previous by Thread: RE: Linking to graphics: why, why not?
Next by Thread: Graphics dpi for .pdf

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

Sponsored Ads

Sponsored Ads