8
Replies
Peter already outlined the most important points. This is a one-way street, and the owner of a FrameMaker document won't be happy about the format conversion, I think. Usually these people NEED to have access to the translated files, if only for backup purposes. Technical documentation has some very strict rules sometimes. He wouldn't be happy about Word files, too 
From my personal experience and tests of the MIF filter: if your FM document is very clean (no style overrides), the result looks very convincing on the first look. However, there are some basic concepts which are handled differently in both applications. One example is space above/below paragraphs. FM always uses the bigger one (but only one), when two paragraphs follow each other. InDesign adds the two values. In order to mimic the FM appearance (when converting to strictly keep the FM layout), the filter creates tons of paragraph style overrides, which makes your target document no longer clean. Or: InDesign doesn't support numberings in header/footer variables (at least up to CS4, don't know about CS5). So if the FM documents has such elements in the header/footer area, it will fail in ID. Next possible problem: cross references. ID's abilities to handle these are much smaller and sometimes unreliable, especially when xrefs point to separate documents (like chapters in a book).
On the other hand, a translation process to any language which is supported by FM (which is the majority, as long as it's not about R2L languages like Arabic or Hebrew) is very simple and straightforward. Feed FrameMaker MIFs into Trados (or another TM), do the translation in the Tag Editor/Workbench, and export translated MIFs again. The result should be a very clean FM document, which doesn't mean any more efforts for formatting than a strict InDesign based (INX, IDML) translation workflow.
Yes, I'd call it a high risk you're taking there, just because YOU know ID better, me thinks…
I'm through all that. The manuals we write are usually translated into 20-30 languages, including e.g. Arabic (that's what I needed the ID versions for), all European languages, and Chinese and Japanese. We're doing all the final DTP work after translation. I'd avoid changing the format whenever possible, it's twice the work.
Bernd
Be.eM wrote:
Peter already outlined the most important points. This is a one-way street, and the owner of a FrameMaker document won't be happy about the format conversion, I think. Usually these people NEED to have access to the translated files, if only for backup purposes. Technical documentation has some very strict rules sometimes. He wouldn't be happy about Word files, too
From my personal experience and tests of the MIF filter: if your FM document is very clean (no style overrides), the result looks very convincing on the first look. However, there are some basic concepts which are handled differently in both applications. One example is space above/below paragraphs. FM always uses the bigger one (but only one), when two paragraphs follow each other. InDesign adds the two values. In order to mimic the FM appearance (when converting to strictly keep the FM layout), the filter creates tons of paragraph style overrides, which makes your target document no longer clean. Or: InDesign doesn't support numberings in header/footer variables (at least up to CS4, don't know about CS5). So if the FM documents has such elements in the header/footer area, it will fail in ID. Next possible problem: cross references. ID's abilities to handle these are much smaller and sometimes unreliable, especially when xrefs point to separate documents (like chapters in a book).
On the other hand, a translation process to any language which is supported by FM (which is the majority, as long as it's not about R2L languages like Arabic or Hebrew) is very simple and straightforward. Feed FrameMaker MIFs into Trados (or another TM), do the translation in the Tag Editor/Workbench, and export translated MIFs again. The result should be a very clean FM document, which doesn't mean any more efforts for formatting than a strict InDesign based (INX, IDML) translation workflow.
Yes, I'd call it a high risk you're taking there, just because YOU know ID better, me thinks…
I'm through all that. The manuals we write are usually translated into 20-30 languages, including e.g. Arabic (that's what I needed the ID versions for), all European languages, and Chinese and Japanese. We're doing all the final DTP work after translation. I'd avoid changing the format whenever possible, it's twice the work.
Bernd
Hi, Bernd:
You've identified the key risky decision points - translations, and "round-tripping" from FrameMaker to InDesign to FrameMaker. All the troublesome artifacts of converting FrameMaker to InDesign via MIF Filter may not be deal-breakers; it depends on the project requirements. I'd like to point out that it's not MIF Filter's fault - the problems are due to InDesign's lack of exact counterparts for the features you noted. Any conversion tool would have to fake the FrameMaker behavior in order to obtain an InDesign conversion so near-perfect that its pages could be overlaid on the FrameMaker pages and be in very close register.
MIF Filter's preferences offer choices on converting some features, but compromises and overrides aren't eliminated completely. Although InDesign can convert overridden styles to new style definitions, with options on the Type menu, each overridden variant would create a separate new style; depending on how much custom overriding was done, as you said, there could be "tons."
I'm curious about which FrameMaker heading/footing numbering properties you've found that aren't supported in InDesign. There are some book-level variables that InDesign lacks, such as $volnum and $volname.
Some users report problems with InDesign's cross-file cross-references. DTP Tools' commercial Cross-References Pro plug-in for InDesign has all the cross-reference format features that FrameMaker offers, plus some additional features; both FrameMaker and Cross-References Pro's features exceed InDesign's.
Regards,
Peter
_______________________
Peter Gold
KnowHow ProServices
AdChoices