Saved file in earlier version format does not show some characters

[Alele58]

I have the 2019 release of FrameMaker, updated to the latest version, my colleagues have the 2015 version of the software. I saved the files in the mif 7.0 format, so that their program can read it, but when they open the documents, FM does not display or recognize a bunch of characters (accented letters, ñ, bullet points, etc.) even though they are in the same language and font. 

The only way we have found to resolve the issue has been to search and replace all the characters that were not recognized (as they were replaced by a "?" character), because it was an urgent matter, but I'm hoping to solve it for good.

Attached are a screeshot of the error, and a screenshot of the problem in the opened file by the earlier version of the program.

[Jeff_Coatsworth]

Wouldn't saving as MIF 7.0 be before the Unicode barrier? It's going to drop any Unicode stuff I would imagine. What about back-saving to a higher version?

[Alele58]

Higher versions don't have problems, but my colleagues' older 2015 version can't open them. The only way for them to open any file that I process through my latest version FM is to save the files in MIF 7.0, which seems to be the only format both versions can process, but without those characters.

[LinSims]

You can save to MIF versions equivalent to each of the FrameMaker versions, but you have to do it through a script.

Rick Quatro has one called ConvertDocs that converts FM files between versions and also to the equivalent MIF version. That is, if you're using FM2017, it will convert to MIF2017. MIF2017 is readable by FM2015, FM2015 will just ignore features it can't interpret. It will also convert from FM2017 to FM2015 or FM2015 to FM2017.

[Bob_Niland]

If the interchange needs to be from any versions in the FM9 to FM2019 (and later) range back to FM8-2017, do not use MIF7. Use the latest MIF generated by the higher FM version. The lower version will pop a dialog advising of potential lost features, but if the documents were authored to avoid newer features, just click on through.

Any version of FM can open any other versions MIF files, but the FM7:8 Unicode border should only be crossed when absolutely necessary, due to the amazing complexity of character encoding possibilities (some of which is captured in my earlier reply on one strategy to manage that).

If FM2015 actually can't open a MIF2019, Adobe needs to know.

[Bob_Niland]

FM7\8 is the Unicode border. Porting forward results in some (FM internal, and some document text) characters to be converted from legacy FM codepoints to Unicode. I suspect that saving-back as MIF7 from later versions doesn't entirely undo this.

If you have to do this migration regularly, I would suggest implementing all non-keyboard (non-Latin1 non-ISO/IEC 8859-1) characters as Variables. The convention I use for naming these is:
U+#### UNICODE FORMAL NAME
The Definition varies for FM7.2 and earlier vs. FM8 and higher.
FM7- would typically use some: <ChFormatName>\x## definition.
FM8+ would typically use a simple: \u#### definition (but might also need a ChFmt if the Body font doesn't populate the codepoint.

The U+ naming causes these to all sink to the tail end of the Variable Catalog, and self-sort by Unicode code point (mostly, SMP is a double issue).

To ease transport, create a mostly empty FM document (or MIF snippet) that contains the local system Variable defs.
Import » Format [✓] Variables
from it on document(s) arrival. This eliminates needing to search for things (that often masquerade as arbitrary ASCII letters in FM7-).