FM9, Mif2Go, and Cross-Refs

[Jeremy H. Griffith]

On Fri, 28 May 2010 12:07:57 -0400, "Martha Lee" 
<martha.lee at coventor.com> wrote:

>If I do steps 1-4 as you suggested below, I get the figures 
>and tables numbered as I wanted them. 

Very good!  We may add a more automated way of doing it
in our next release, which we've been working on for the
last year and which is almost ready.

It would require more memory, so it would be optional.
We would have to open all files in the book at once
(and some of our customers have over a thousand), then
import the conversion template to the book in one step,
then update all the files.  All without saving.  Then
make all the .mif, close all the .fm files, and continue
with the conversion process.  Not hard at all to program,
but might be a lot slower and would definitely be much
more demanding of memory.

>But the question remains: why was I able to do this 
>in my previous versions of FM and Mif2Go, and not now?

No idea.  We haven't changed our basic processing rules
for some years now, and doing one chapter at a time,
with the rest still using the *previous* numbering
formats, it's hard to see how it ever worked as you
wanted.  At update, when Frame gets the xref content
from the referenced files, it would always see the old
numbering.  Even if it cached the previously-processed
files after their template import and used those images,
it would still get the old formats for the following
files.  So at least some of the inter-file xrefs would
have used the old numbering.

If you are talking about xrefs *within* the same file,
a possible explanation could be a difference in Frame's
caching rules from 7 to 9.  It could be that in FM9,
the xref content as it was *before* the template import
is cached; then if the cache were not flushed when the
template is imported (as it should be), your update would 
get the old values.  Perhaps importing the template to 
the book forced a cache flush.  But this is speculation;
the bottom line is, now you have a way to proceed that
works.

-- Jeremy H. Griffith, at Omni Systems Inc.
  <jeremy at omsys.com>  http://www.omsys.com/