I had to do some work while I was on vacation but didn't have my work PC so I opted to download a trial version of FM15 and asked a co-worker to send over the files I needed.
Now, back at the office I cannot open the .book created in FM15 in my purchased version of FM12.
The options I tried were to Save as: Document2019 (.*fm), MIF 2020 (*.mif) and MIF 7.0 (*.mif)
For each, when I attempt to open in FM12 I get this error message: "Although [this file] appears to be a FrameMaker document, it can't be opened with this release of the product."
Please help 🙂 I'm going on maternity leave on Friday and can't leave my replacement with this mess 🙂
I am sure there must be a way to bipass this because when we receive documents from our translators, I often see a message stating that the document was prepared in a newer version of FM and that some features may not be available or something of the sort.
Thank you to anyone who may have any suggestions!
The MIF (7.0) one should have worked no problem - did you have a look at the .mif file after creating it? You should be able to open it with Notepad and see the contents (not that they'll make much sense).
Yes I tried opening it and got the same error, I'll try again.
Update: I can open in Notepad to see the gibberish but get the same error message in FM2015 when I attempt to open. The one that states that it can't be opened with this release of the product.
MIF 2019 should have worked, and is preferrable to MIF 7 when both FM versions are FM8 or later.
Using MIF could strip a lot of features, and mess up character coding.
Bob, would the MIF 2020 version be a better choice for porting back to FM2015? IIRC, newer FM features just get ignored when an earlier version of FM opens a MIF file with those newer bits in it, right?
Jeff, there are likely at least two problems with using MIF7 when porting back to FM8 or later.
One I just finally poked into: Unicode
When saving back to MIF7, FM8+ tries to convert any Unicode to such special characters as existed in FM7.
For example, U+00B7 MIDDLE DOT gets converted from a plain "·" to "\xe1".
When it can't, it sends them back as literal "?" (ASCII 3Fh).
For example, U+2116 NUMERO SIGN "№" is sent back as "?".
Most Unicode is lost, irrecoverably.
I further suspect that any markup constructs not supported in FM7 might be discarded, but haven't tested it. The Unicode damage suffices to keep me from using MIF7 where the recipient app is FM8 or later. From a stewardship standpoint, of course, there's no harm saving as both.
Another question about versions - were you using FM2015 or the new version FM2020?
Originally it was a FM2015, then I opened it in FM2020 to make the modifications and now need it to be opened by FM2015 again.
As I said, the MIF7 version should have worked fine (all the way back to FM7), but maybe there is a bug in FM2020 with .mif creation (FM2020 is brand new). Have you tried running any patch on it & saving again? Would you like to send one of the .mif files to me to see if I can open it? Send me a PM if you'd like to try that.
Aw you're too kind! Yes I will send, thank you so much for investing some time into my little dilemma. It is much appreciated.
And no @ patch - wouldn't be too familiar with that but I imagine I could find some information on how to do so 🙂
So it seems that the issue was that the Save As MIF didn't get the .mif extension on the file (which then prompted the issue in FM2015 when it tried to open it).
Yes thank you so much - Saving as .mif solved the issue.