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: Warning re: importing by reference From:Michael Christie <Michael_C2 -at- VERIFONE -dot- COM> Date:Thu, 27 Aug 1998 12:37:55 -0700
Or...
Document
Frame
Graphics
which makes the graphics directory a subdirectory of the directory
containing the Frame files.
I almost always use import by reference, and avoid copy into document
whenever possible. I often deal with changing UI's, which means changing
screen shots. By using import by reference, I replace the new screen shot
with the old, and I'm done. I don't have to worry about taking the new
screen shot *and then* copying it into my document. Makes life simpler.
Mike
Mike Christie
Senior Information Developer
VeriFone, Inc.
MikeC -at- verifone -dot- com
408 919-5729
> -----Original Message-----
> From: Scott Wahl [SMTP:swahl -at- BRIDGEWATERSYS -dot- COM]
> Sent: Thursday, August 27, 1998 12:22 PM
> To: TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU
> Subject: Re: Warning re: importing by reference
>
> Hi all,
>
> One caveat to Beth's argument against importing by reference. We need to
> make the
> distinction between an "absolute" path and a "relative" path. An absolute
> reference
> might look like this "c:\winnt\profiles\swahl\desktop\graphics".
>
> You can make the reference to the graphic a "relative" one by using a
> simple
> directory structure:
> Document
> Frame
> Graphics
>
> You put the Frame files in the Frame folder and your graphics in the
> Graphics folder
> *before* you import the graphics. Frame sets the reference to the graphics
> as
> relative to the Frame file, rather than as an "absolute" path that starts
> at the
> hard drive. The relative path in this example would look like
> ":Graphics".
>
> This allows you to import graphics by reference without making the
> references
> dependent on a particular hard drive or server. You can move the Document
> folder
> anywhere and the graphics will always appear. The only way this gets
> messed up is
> if you change the name of the Graphics folder.
>
> Regards,
>
> Scott
>
> Elizabeth Kane wrote:
>
> > Suzette,
> > Just a few words of warning about "import by reference" -- I NEVER
> use
> > it, because copying the graphics into the doc is so much simpler,
> > safer and (in my case) really doesn't add an intolerable amount of
> > size to my files. The trouble with importing by ref is that any
> time
> > you copy or move those chapters to another location, you have to
> make
> > sure to also copy every one of the graphic files that are imported
> by
> > ref. You might also have to redefine the path to them. It's a pain!
> > What if you lose one of them, or they all get deleted by mistake?
> The
> > only way to make the file usable again is to recreate the captures.
> > That's too much work to take a chance on, for me.
> >
> > These days I'm having quite a time coping with a really bad
> situation
> > caused by import by ref: our graphics guy was laid off, and I
> offered
> > to maintain his huge archives. Right after he left, the MIS guy
> backed
> > up his art docs onto tape. Then his Mac's hard drive died.
> >
> > So we had to use the tape to restore all his files onto my machine.
> > But every time I open a doc, I get an error message saying
> associated
> > graphics files are missing. He used import by ref in every one of
> his
> > docs, and sometimes there are 6 or 8 files I have to track down.
> > Because the path to the files the doc was dependent on cited his
> hard
> > drive name, and it's dead now, every file has to be fixed! I'm
> working
> > unpaid overtime as a result.
> >
> > Beth Kane
> > bkane -at- artisoft -dot- com in Tucson
>
> --
> Scott Wahl
> Customer Documentation Coordinator
> Bridgewater Systems Corporation
> (613) 591-6655 x.2579
>
> From ??? -at- ??? Sun Jan 00 00:00:00 0000=
> =
>
>