Re: Importing images by reference rather than by embedding...

["Thomas Michanek" <thomas.michanek@xxxxxxxxx>]

*** The original message appeared on the FrameUsers mailing list.
*** This reply is sent only to the "Free Framers" mailing list.

From: "Emily Berk" <emily@xxxxxxxxxxxxxxxxx>
> When I search the archives, I find only arguments for importing by reference.
> Can anyone report instances in which embedding the graphical images (and
> NOT importing graphics by reference) was the way to go and why?

Emily, I'd like to offer a more complete summary of the arguments for
and against both import methods, here copied to the Free Framers list.
This summary was posted to the FrameUsers list on June 1st, 2004.
If anyone disagree or have questions, feel free to reply to the list.

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 filesize 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 filesize for FM documents (no image data stored)
+ FM documents become faster to open and save (due to smaller filesize)
+ Total filesize 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)
- 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 accidently 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 accidently 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 screendump of the FM page and loose any vector data)
- FM documents become larger (filesize) 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)


___________________________________________
Thomas Michanek, FrameMaker/UNIX/MIF expert
Technical Communicator, Uppsala, Sweden
mailto:Thomas.Michanek@xxxxxxxxx
http://go.to/framers/
___________________________________________

Join the "Free Framers" mailing list: send an email to
majordomo@xxxxxxxxx with "subscribe framers" in the body


** To unsubscribe, send a message to majordomo@xxxxxxxxx **
** with "unsubscribe framers" (no quotes) in the body.   **