Does FM crash on Large files on a regular basis?

[Jeremy H. Griffith]

On Thu, 8 Jan 2009 13:24:48 -0700, "Combs, Richard" <richard.combs at Polycom.com> 
wrote:

>Actually, it's much worse than that. "Visio embedded drawings" are _not_
>embedded graphics (in the FM sense) -- FM doesn't have an import filter
>for Visio files. They're actually embedded OLE objects. Much more of a
>problem than embedding graphics files -- there's lots of overhead
>involved with OLE and more chance for things to break. 
> ...
>I suspect OLE objects are beyond even Mif2Go's prodigious capabilities.

Nope.  ;-)  At least, not when they represent Visio files.
One of our customers (Intel) actually discovered this, and
told us about it.  It turns out that if you export the OLE
objects with Mif2Go, and rename the files from .ole to .vsd,
you can open them in Visio just fine.  Use this setting
in mif2htm.ini:

[GraphExport]
ExportOleFiles=Yes

That will make the *.ole files in the output directory.
You need to rename them, perhaps with a console command:

C:\>ren *.ole *.vsd

If you were actually using them in Mif2Go outputs, you'd
rename them with a BookFileCommand, and also set:

[GraphSuffix]
ole=vsd

so that the HTML Mif2Go produced referenced them correctly.

When the OLE objects do *not* represent Visio files, you 
don't use ExportOleFiles=Yes.  Then Mif2Go goes through
the OLE objects and hunts down a likely WMF, and exports
*that*.  Sometimes if there are multiple WMFs it will
choose the wrong one, in which case you can set:

[GraphExport]
MultipleOLE=Yes

and we'll output *all* of them.  This is in the User's Guide
par. 29.2.3.7, "Setting export options for OLE objects".

HTH!

-- Jeremy H. Griffith, at Omni Systems Inc.
  <jeremy at omsys.com>  http://www.omsys.com/