Word is not FrameMaker. Although Mif2Go does a good job of emulating FrameMaker features that do not exist in Word, there are limits. You can easily create in FrameMaker constructs that are beyond the capabilities of Word.
FrameMaker and Word implement autonumbering quite differently. By default, autonumbers become plain text in Word. For review purposes, what is important is the accurate text depiction of autonumbers in Word. When Mif2Go renders autonumbers as plain text, the numbers stay fixed, even if a reviewer interpolates a new list item. You do not want the numbers changing in a review situation; it makes the real changes harder to find among the artifacts. However, Mif2Go can generate live autonumbers in Word, as SEQ fields; see §5.5.5 .
Some FrameMaker formats are renamed by Word itself, not by Mif2Go. For example, if you have paragraph formats Heading and heading in your FrameMaker document, Word calls the second format heading1, because in this respect Word is not case sensitive. Also, if you have a character format with the same name as a paragraph format, Word treats them the same; in Word, it is just one namespace.
Many common FrameMaker page layout features, such as headers that extend down next to the body text, do not work in Word. You might have to redesign master pages, or replace master pages temporarily by importing a conversion template. See §5.4.1 .
Word does not support rotated text or rotated tables. Word does not even support rotated table cells; but see §5.11 for a workaround.
Sideheads go into RTF text boxes. This works well when the text box is created in RTF; but try creating another like it in Word, or even try adjusting its position in Word, and you get a real mess. If you want to be able to add new sideheads in Word, you have to convert existing sideheads from FrameMaker as plain left-aligned heads. If your sideheads are in text frames inside anchored frames, each such text frame has to be alone in its anchored frame.
By default, anchored frames are rendered as graphics in Word. You can tell Mif2Go to render anchored frames as text when possible; see §184.108.40.206 . Although this works when there is a single text frame in the anchored frame, it does not work when the anchored frame contains multiple text frames or both text and graphics. Word cannot nest text boxes.
Word does not support Frame Above or Frame Below paragraph properties. To emulate these properties in Word, for each such frame Mif2Go inserts a small metafile in the RTF output; see §5.5.7 for a way to eliminate the frames instead.
Word and FrameMaker compute the vertical space between paragraphs differently; it is not always possible to achieve an exact match. See §5.8.2 .
The equation engine in FrameMaker actually models the mathematics; equations in Word are for display only. WMF images created by FrameMaker (and by Mif2Go) for equations produce sharp images. Mif2Go uses FrameMaker graphic export filters to make an image (WMF, for Word) of the frame containing the equation, then embeds that WMF in the Word RTF at a size based on the FrameMaker original, scaled as you specify. By default, Mif2Go enlarges equations a bit to improve readability; you can specify exactly how much. See §4.11 .
Unlike FrameMaker, Word does not include change bars as a text property. Instead, Word uses Revision Tracking, which is a far more complex way of identifying changes. Revision Tracking requires information that FrameMaker does not include. Therefore, Mif2Go support for converting FrameMaker change bars is limited to giving Deleted text the strike-through property in Word. To make this work, you would have to Show (rather than Hide) the Deleted conditional text in FrameMaker, possibly by using a conversion template; see §2.4 . Mif2Go does not identify Inserted text; you would have to use a character format.