Summary: FrameMaker graphics: Link vs Embed (long)

[beverly_robinson -at- datacard -dot- com]

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
to
  FM documents where the same image files have been copied/embedded
+ Easy to update/replace an external image file and have the change
reflected
  everywhere in all FM documents automatically (without having to
re-import)
+ You can double-click an image in FM and have it open in the default image
editor
+ Possible to have different versions of the same image, with the same
filename
  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,
Word)
+ (added by BR from replies received) Permits sharing a common graphic
across
  publications and authors. (See discussion of image management at end of
this
  message.)
+ (added by BR from replies received) Text can be more easily updated
without
  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
discover
  the problem if those image files stay put, and creating a ZIP file won't
give
  you a "stand-alone" package anymore (common mistake)
- Importing "template images" on master and reference pages by reference
may
  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
may
  need to re-import the image to avoid distortion of the image (common
problem)
- Displaying an image may take longer since the external file has to be
read
  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
displayed.
- If an external image file is accidentally deleted, you have lost the
image
  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
files)
+ FM documents can be moved in the file structure, transferred to other
file
  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,
especially
  if you include "FrameImage" facets (which even more increases the file
size)
- You have to manually locate and re-import images everywhere when they're
updated
  (there's no way to have FM keep track of the images since filenames are
lost)
- You'll get duplicate copies of images that are used in more than one
place
- If you've lost the original image file, editing an image becomes
difficult
  (you may need to make a screen dump of the FM page and loose any vector
data)
- FM documents become larger (file size) and slower to handle (finally, FM
may
  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
internally,
  thereby losing the size advantage of image compression (GIF and TIFF are
OK)
- 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
bug
  (the bug effectively deletes all embedded images without telling you, and
  you must copy/paste all images from backup copies, if you still have
them)

-----------------------

David Neeley provided this suggestion about managing images:

I suggest if you have not already done so that you think through the image
management
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! 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.