[Date Prev][Date Next]
[Thread Prev][Thread Next]
[Date Index]
[Thread Index]
[New search]
To: <beverly_robinson@xxxxxxxxxxxx>
Subject: FrameMaker graphics: Link vs Embed
From: "Thomas Michanek" <thomas.michanek@xxxxxxxxx>
Date: Mon, 31 May 2004 22:12:04 +0200
Cc: "Free Framers" <framers@xxxxxxxxx>
Delivered-to: jeremyg-freeframers:org-ffarchiv@freeframers.org
References: <OFA9B4F032.37F9DD83-ON86256EA0.0066F265-86256EA0.0067CF76@datacard.com>
Sender: owner-framers@xxxxxxxxx
> Are you aware of any documents that do discuss the advantages and > disadvantages of the import methods? My work group is getting hung up on > this question and I'd like to point them to a dispassionate discussion. Beverly, You've received a number of replies to this query on the FrameUsers list, but I'd like to offer a more complete summary, copied to the Free Framers list. Feel free to forward this to the FrameUsers list, if you wish. 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. **