The reason the Excel spreadsheet is linked is that when the Excel is updated, in Framemaker it gets updated as well.
Well, that's the theory anyway. This forum has hundreds of posts about the reality of OLE.
If the spreadsheet is used only to provide tables for FM, OLE is simply not worth the hassle vs. exporting selections to PDF.
If the spreadsheet is primarily used for other purposes, and FM is merely siphoning off some of it, the hazards of OLE could easily outweigh the benefits.
What happens when the XLS maintainer inserts/deletes a row/column, renames a sheet, or makes some other significant but entirely typical edit that radically affects what FM is relying on? With OLE, there is no intermediate object. As soon as you open the FM document, the prior import is gone.
Sure, you can flag the sheet with dire warnings about that, but then you could also include the how-to-export instructions (which is what we do). Our normal backup system snags copies of the prior imports, should we need to revert or compare.
And then there's translation. It may not be an issue for you, but I often have to prepare manuals for external translators as FM source. Because all of the imported content is from files (not via OLE from apps), we can re-path the references and zip it all up easily. With OLE, they'd have to have the same [rev} app mix, and we'd have to supply complete spreadsheets, which might contain sensitive data or rely on further references (e.g. DB queries) not available outside the enterprise.
Apart from the stewardship issue, your minor character encoding issue could be just the first of many OLE problems you are about to face.
4
Replies
AdChoices