Summary: FrameMaker graphics: Link vs Embed (long)

Subject: Summary: FrameMaker graphics: Link vs Embed (long)
From: beverly_robinson -at- datacard -dot- com
To: "TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com>
Date: Tue, 1 Jun 2004 10:55:50 -0500

Cross-posted to Techwr-L and Framers

Last week I asked for a dispassionate discussion of the pros and cons of
importing graphics by reference versus by copying (linking vs. embedding).
Thanks to all the people who replied on and off list.

Twenty people expressed a preference, and all of them prefer importing by
reference (linking). Two people noted that they import by copying in
special circumstances (Visio diagrams and note/caution icons).

Thomas Michanek provided the following summary of the pros and cons and
gave me permission to forward this to the lists. I've added some items from
your posts:

First the difference between the two methods:

1) Import by reference (linking): only two things are stored for the
imported graphic: its path/filename and the graphic filter used.
The filter identifies the image format, not the file extension.
The existence of all graphics imported by reference is checked when
the document is opened, and the Missing File dialog may be shown.
It is then easy to re-link missing image files to their new location.
When the graphic needs to be read or displayed for the first time,
the linked image file is read and interpreted by the graphic filter.
This also happens each time the external file has changed on disk.
If the file is unreadable or the filter is missing or encounters an
error, a gray box is shown. Filters differ between platforms and
FM versions, so images may be grayed out even if the file exists.

2) Copy into document (embedding): a copy of the imported graphic is
stored, using one ore more internal FrameMaker "facets". The path
and filename of the original graphic is lost. The "facets" are
stored in external temporary files when the graphics are displayed.
Not all facets are supported on all platforms and FM versions, so
images may be grayed out even if the facets are stored correctly.
To prevent this, an extra cross-platform "FrameImage" facet may be
stored for each graphic, and this is controlled by an FM preference.
Some facets are not stored compressed, including JPEG and PNG, which
makes the FM file size grow much more than the original image file.
Facets may be permanently lost under unlucky circumstances due to
an old FM bug concerning the temporary files.

NOTE: this excludes the method of using OLE links for images.

The above pretty much determines the pros and cons for each import method:

Import by reference (linking), plus and minus:
+ Smaller file size for FM documents (no image data stored)
+ FM documents become faster to open and save (due to smaller file size)
+ Total file size of FM documents and image files is often smaller compared
FM documents where the same image files have been copied/embedded
+ Easy to update/replace an external image file and have the change
everywhere in all FM documents automatically (without having to
+ You can double-click an image in FM and have it open in the default image
+ Possible to have different versions of the same image, with the same
but in different locations in the file structure, and switch between them
(especially useful when translating documents to other languages)
+ You can generate a list of imported image files, and you can always check
the image filename and thereby reuse an image in another document
+ As long as the external image files are kept and you work on the same OS
and FM version, you won't risk losing any graphics
+ Faster and easier conversions to other document formats (HTML, Help,
+ (added by BR from replies received) Permits sharing a common graphic
publications and authors. (See discussion of image management at end of
+ (added by BR from replies received) Text can be more easily updated
the time-consuming loading of large graphic images.
- If you want to move, transfer, e-mail, or "check in" a document, you must
remember to include the correct external image files (perhaps by creating
a ZIP file of the document and a graphics subfolder)
- If you only are allowed to import graphics from a specific subfolder, but
you accidentally import them from other disks and folders, you may not
the problem if those image files stay put, and creating a ZIP file won't
you a "stand-alone" package anymore (common mistake)
- Importing "template images" on master and reference pages by reference
cause link problems when documents are created from such templates (links
become broken or points to the template's image folder)
- If a new version of an image has a different size or aspect ratio, you
need to re-import the image to avoid distortion of the image (common
- Displaying an image may take longer since the external file has to be
and interpreted (instead of just displaying an internal copy). This delay
also occurs when you print a page with an image that haven't been
- If an external image file is accidentally deleted, you have lost the
in all documents (since no internal copy is stored)
- If an external image file is moved or renamed, you have to manually fix
these problems afterwards by re-linking the image files (which is easy)
- Increased risk of cross-platform compatibility problems for image formats
(not all formats are supported equally on all OS and FM versions)

Copy into document (embedding), plus and minus:
+ All information is kept in a single file (no need to keep track of other
+ FM documents can be moved in the file structure, transferred to other
systems, e-mailed, checked into revision control systems, etc. without
having to worry about external files
+ Less risk of cross-platform compatibility problems for image formats,
if you include "FrameImage" facets (which even more increases the file
- You have to manually locate and re-import images everywhere when they're
(there's no way to have FM keep track of the images since filenames are
- You'll get duplicate copies of images that are used in more than one
- If you've lost the original image file, editing an image becomes
(you may need to make a screen dump of the FM page and loose any vector
- FM documents become larger (file size) and slower to handle (finally, FM
start complaining that there isn't enough memory to open the file)
- You have no way of knowing where an image originated from, or whether two
seemingly identical images really are identical
- JPEG, PNG and some other image formats are stored uncompressed
thereby losing the size advantage of image compression (GIF and TIFF are
- Difficult to localize/translate documents, if images need to be edited
- In a worst case, you may loose some or all your images due to a rare FM
(the bug effectively deletes all embedded images without telling you, and
you must copy/paste all images from backup copies, if you still have


David Neeley provided this suggestion about managing images:

I suggest if you have not already done so that you think through the image
problem. If you have an image catalog, it should contain the pertinent
details about
the image in a searchable database of some sort--including image creation
date, source,
brief description, and even what docs use it and/or what "chunk" it appears
with if
you're doing single sourcing. In other words, enough information to
determine when an
image should be updated or when a new one should be created in cases where
there are
still old versions needed for one reason or another.

If this image catalog is available to all tech writers at a common
location...and the
masters are set as "read only" where the writers are concerned, then all
the linking
will be standardized and when you print a doc the links will still be
good--whether you
print to a physical device or to .pdf.

If and when you must send out a book to be offset, you'll also have your
links all to
be updated en masse...again saving time and effort. (Of course, I'd do a
high-res .pdf
and print from that, so that the graphics would be part of the file...).

. . . you retain much more flexibility with this linking approach and can
be much more
productive. Also, as various individuals create a new graphic for use in
any doc, by
making it a part of your graphic catalog it is then available to all who
may need it...
and you keep from "reinventing the wheel" too many times over. With the
graphics catalog
approach, you have both convenience and control...and it is easy enough to
find a
particular graphic that people are not tempted to recreate it simply
because they can't
find the one they "seemed to remember".

Thanks again to all who responded.

Beverly Robinson


SEE THE ALL NEW ROBOHELP X5 IN ACTION: RoboHelp X5 is a giant leap forward
in Help authoring technology, featuring Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more!

>From a single set of Word documents, create online Help and printed
documentation with ComponentOne Doc-To-Help 7 Professional, a new yearly
subscription service offering free updates and upgrades, support, and more.

You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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 for more resources and info.

Previous by Author: RE: Instructions
Next by Author: Re: upload/download terminology
Previous by Thread: Two monitors and KVM
Next by Thread: Re: Vertical Ellipsis in Word?

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

Sponsored Ads