poshedly at bellsouth.net wrote:

> I also have had problem-FrameMaker files where the author at the home
> office in Europe forgot to embed the images files before sending me
the FM
> file.
> 
> The result was lost time and effort. And to make matters worse, they
> sometimes sent me the image files themselves for me to embed, but the
> company uses identical names for images files used in different books.
> 
> So when I placed images files in a directory common to a "family" of
> books, I unknowingly overwrote previous image files that were totally
> different. This was finally caught before final printing, but it was
--
> and still is -- a pain in the butt.
> 
> And yes, I've tried to set them (the home office) straight with
> alternative ways to name images file, but no luck yet.
> 
> Thus, large FM files with embedded images are best for my particular
use.

FM files made large by embedded images are a different issue. The OP was
talking about a single FM file that contained an entire 300-page book, a
truly terrible idea. IMHO, embedded images are a bad idea, too -- but
not that bad. :-) 

As for your file name collisions, I strongly recommend a separate
graphics directory for each book, under the book's directory. A few
shared graphics, such as a corporate logo or product picture, can go in
a shared location. For instance: 

../Whizbang1000/Getting_Started
../Whizbang1000/Getting_Started/graphics 
../Whizbang1000/User_Guide 
../Whizbang1000/User_Guide/graphics 
../Whizbang1000/shared_files

Even if you insist on embedding graphics (boo! hiss!), you should have a
system to identify, keep track of, and safeguard the source files for
those embedded graphics. If you ever open an FM file with embedded
graphics and see nothing but gray boxes, you'll be so very relieved if
you have all the source files at hand. :-)

IMHO, YMMV, etc.

Richard

Richard G. Combs
Senior Technical Writer
Polycom, Inc.
richardDOTcombs AT polycomDOTcom
303-223-5111
------
rgcombs AT gmailDOTcom
303-777-0436
------





Reply via email to