Frame to MIF to Frame to MIF to Frame

[mellon89]

What happens when you have cross references from one chapter to another and save those fm 11 chapters as mifs, which get converted to fm and edited in an earlier version fm 7, then saved as mifs, and then are opened again in fm 11 with  the rest of the chapters in the book?

[Art_Campbell1]

Be sure to let us know when you find out. ;- )

My best guess would be that if no one mucks with the CRs in 7, they'll be

intact. FM is supposed to ignore contents in the MIF that it doesn't

understand. So the 11 CRs should pass through 7 and back into 11 intact. In

theory. And assuming the files all end up in the same book and they're all

in the same relative path as when they started.

If I were you, I'd try to eliminate the problem by getting the 7 site or

writer upgraded, even temporarily, with an 11 eval.

Art Campbell

art.campbell@gmail.com

"... In my opinion, there's nothing in this world beats a '52 Vincent and

a redheaded girl." -- Richard Thompson

No disclaimers apply.

DoD 358

I support www.TheGrotonLine.com, hyperlocal news for Groton MA.

[mellon89]

In this case many of the CR's are updated in FM7, which is where I believe the problem starts.

[Arnis_Gubins]

Some cross-ref issues may result from the location of the files (i.e. the folder structures) used on the various machines. If there are links between files in different folders, you have to be careful that the link doesn't cross the root of the drive, e.g. D:\Project1\a.fm linked to D:\Project2\b.fm would cross the "root", whereas D:\Projects\First\a.fm linked to D:\Projects\Second\b.fm does not.

When the link crosses the root, FM makes the link absolute, i.e. the entire filepath is embedded. Otherwise, when linking between folders at a lower level, FM just uses the relative path. You also have to be careful that the folder names along the relative paths remain the same on the various machines.

[mellon89]

Arnis,
Thank you. That is definitely good information to know (re: realtive and absolute link creation).

In this case I'm using FM11 on my machine, saving as MIFs and sending to a colleague using FM7 on another machine. He then sends me back the edited files in MIF. All files on both machines are in one folder (essentially no path difference bethween the files and the cross references).

W.R.T. best cross reference preservation:

Question 1: Should he edit the MIF files or 1st save as FM files and then edit.

Question 2: Does/should he need to save the files as MIF before sending back to me, or can FM11 open FM7 files in FM format?

BR,

Clint

[Arnis_Gubins]

Clint,

It doesn't matter what format is edited or saved. MIF is the human readable ASCII version of the internal FM database. When FM has opened a file, it is all in the internal binary format that FM is working with. The only difference is when saving the file. Saving as MIF goes through a very specific process, so accidental inclusion of cruft (such as may come in from a Word copy & paste) in the binary gets stripped out when saved as MIF.

If, as you say, all of the files are in the same folder, then there shouldn't be any issues with cross-references (other than the use of unicode characters) between FM versions.

Nothing has changed in the FM cross-ref mechanism in a very long time, so I really don't understand the concern about cross-reference preservation. Are you encountering specific cross-ref errors in this FM11 > FM7 > FM11 workflow roundtripping? If so, what specifically are the issues?

FM11 should be able to open the binary versions (.fm) files, so it shuldn't matter if the files are returned as .fm or .mif.

[mellon89]

Arnis,

This has been very helpful.

Based on everthing I've heard, the following appears to be the problem.

The file names of the files edited in FM7, where the xref updates were made, were changed when I received them.

If this was simply done as a name change in the folder before sending to me, and I changed the file name back before I dropped them in the folder where the book is at, overwriting the files currently there, then there should be no problem.

If however, this was done prior to the xref changes, and the files were then saved and sent to me, and I then changed the file name back before I dropped them in the folder where the book is at, overwriting the files currently there, the tags for the relative xrefs will still have the previously modified file names associated with them, which are causing the unresolved xrefs, to show when building the book.

BR,
Clint

[Bob_Niland]

> ... simply done as a name change in the folder ...

Book component files must be renamed only by using the Book Menu feature for that:

right-click componentname.fm

Rename File

Doing otherwise will cause file-to-file references to fail, and may cause generated files to not work either, if indeed the file doesn't just fall out of the book altogether..

[Arnis_Gubins]

Clint,

The file names of the files edited in FM7, where the xref updates were made, were changed when I received them.

If this was simply done as a name change in the folder before sending to me, and I changed the file name back before I dropped them in the folder where the book is at, overwriting the files currently there, then there should be no problem.

No, you can't rename files at the system level! The links are made to the actual filename at the time that the link was made. As Error says, you must use the Book file to rename the files (it takes care of changing the links). However, this means that the files would need to be renamed at every hand-off (FM11 > FM7 > FM11).

The question begs to be asked: why are the names being changed in the first place? Leave them alone and you won't have these sorts of issues.

It also would greatly help you if everyone were at the same level of FM. If this is a contractor doing the work with FM7, then it should be their responsibility to provide you with the appropriate file versions.

[mellon89]

Thank you everyone. This has been very helpful in understanding the issue and preventing it going forward.

BR,

Clint

[Bob_Niland]

> ... saving as MIFs ...

Does FM11 offer a choice of MIF versions, and if so, which are you choosing?

FM9, for example, allows MIF save as MIF9 or MIF7.

Saved as MIF7: If the name, definition or target of an Xref contains Unicode, those characters get converted to "?", but the Xref still works in FM7.1. FM9, however, is making no effort to down-convert Unicode to anything FM7 would support (nor could it, for the vast majority of Unicode glyphs).

Saved as MIF9: The characters may appear in FM7.1, but are \x## \x## escaped byte pairs in the Xref definition, and arbitrary 8th-bit-on roman extension characters in the text. They aren't even escaped to UTF8 triplets. Again, however, no Unresolved Cross-Ref error is thrown on open in FM7.1.

[Arnis_Gubins]

FYI, all versions since FM8 have a save to MIF 7.0 option just for the unicode compatibility issues.

[Arnis_Gubins]

Other than a convoluted workflow, nothing much should happen unless you move the files around between folders. In that case, you would break the cross-refs.

What also might occur is that if some special symbols or characters are used, they may show up incorrectly, as ?? or some other symbols at the end of the round-tripping. FM11 uses unicode encoding while FM7 uses the old FrameRoman encoding.

[mellon89]

Have seen the ?? and others as part of going back and forth.
Only a few files are edited in FM7 and then passed back to be dropped back in the folder where the FM11 files and book are located.