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.
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
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
the image in a searchable database of some sort--including image creation
brief description, and even what docs use it and/or what "chunk" it appears
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
still old versions needed for one reason or another.
If this image catalog is available to all tech writers at a common
masters are set as "read only" where the writers are concerned, then all
will be standardized and when you print a doc the links will still be
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
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
approach, you have both convenience and control...and it is easy enough to
particular graphic that people are not tempted to recreate it simply
because they can't
find the one they "seemed to remember".
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! http://www.macromedia.com/go/techwrldemo
>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. http://www.doctohelp.com
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 http://www.raycomm.com/techwhirl/ for more resources and info.