FM 9, limitations for text insets or OLE objects

[Guest]

Hi everyone,

I'm looking at ways to manage duplication of content in unstructured FM9. I'm considering using text insets or Excel objects to allow for reuse. I'm trying to anticipate issues if whatever I decide to use is rolled out to a larger doc set.  So, my questions are:

Does anyone know of any limitations for the number of text insets or OLE objects that can be used in a single FM chapter or book?

Does anyone know if there is a path length limitation between the source content for text insets or OLE objects and the chapters they're used in?

Thanks,

Glynnis

[Bob_Niland]

Does anyone know of any limitations for the number of text insets ...

What format of text insets?

If they are plain text, or you override the source formatting with local (host) document formatting, I haven't seen any limitations.

If you preserve the source formatting, peculiar things happen. See recent {PgfLocked} thread.

... or OLE objects that can be used in a single FM chapter or book?

After taking one look at the visual quality and performance impacts of OLE imports (back when FM first had it), I've avoided it ever since.

We do spreadsheet imports by exporting selections to PDF in the spreadsheet (LibreOffice Calc), batch converting them to EPS, and importing the EPS. Vectors stay vector. Text stays text (and is Acrobat searchable). Zero performance impact. Frame platform doesn't have to have the exporting app.

We use EPS because PDF import is unstable on FM7.x (gets much worse than peculiar very quickly if there's more than a token number of them). On a later FM version, we'd probably just import the PDFs, since that seems to be where Adobe is headed.

[Van Kurtz]

On a later FM version, we'd probably just import the PDFs, since that seems to be where Adobe is headed.

We use both eps and pdf with FrameMaker 9, and both work just fine.

[MichaelKazlow]

Frame has never done well with OLE, I suggest avoiding it at all costs.

[Bob_Niland]

Frame has never done well with OLE, I suggest avoiding it at all costs.

A Google search of:

framemaker OLE problem OR limitation OR issue site:forums.adobe.com

gets 816 hits. Hmmm.

OLE is of course MS Windows-specific. That's now slightly less of an issue than it used to be. We still author on Unix, and so cannot use it, even if it made sense, which I suspect it rarely does.

Frame may only have OLE because MS required it for app cert starting with Win95 (and they may have done that to kill off OpenDoc, and not because OLE confers such glorious blessings on content creators and users).

If you are going to use OLE, you have to understand what it is doing when you drop the object in, how that object will render to print and PDF, how you will keep that object updated, and what happens when the OS, app mix, and originating document radically change. I suspect that OLE often seems to work when the object is first emplaced, but things go off into the weeds very shortly thereafter.

[Art_Campbell1]

There aren't any limitations on text inserts.

The main limitation on OLE objects is the technology doesn't work most of the time -- there are lots and lots of messages about this in the archives and on the Framer's list that you can Google up. This is not so much on the FM side as the OS side.

AFAIK, the only combination that works with OLE objects is FM 10 on Windows 7.

Any earlier versions / combinations are unlikely to work because Micrsofot's handling of OLE objects changed after XP SP3, and it took Adobe a release to catch up and support the newer standard.

Just in passing, I wouldn't rely on OLE ina production environment even with 10 & 7 until I'd tested it for months....

[Guest]

Thank you all for your input. Just a small test of using OLE supports what you've said about it. I'm going to to continue testing only with insets.

Glynnis