Generated chapter TOC obtusely reverts to non-existent formats

[Hedley Finger <hedley.finger@xxxxxxxxxxxxxxx>]

ALTERNATIVE SUBJECT: If you're so smart, figure this one out!

To generate chapter TOCs I normally include a TOC reference page in each
chapter file and add basenameTOC para formats to the file.  Then I can
choose File > Generate/Book, copy the generated TOC from the newly
created filenameTOC.fm file, and paste it into the source filename.fm
file.

The TOC builders on the TOC reference page have the general format of

    <$paratext><numberformat>\sm<$pagenum>

<numberformat> is a char format that ensures the page numbers are all
10pt light roman despite the differing sizes, colours, weights, etc. of
the underlying para formats that vary with at different heading levels.

\sm inserts an em quad (I also insert an em quad with Esc <spacebar> m
depending on the phase of the moon).

What happens when I generate a temporary filenameTOC.fm file is that

@ the <numberformat> builder is ignored and the entire paragraph
including page numbers has the format of the underlying para format,

@ the em-space builder (either \sm or Esc <spacebar> m) is ignored and
is replaced by a normal word space, 

@ when examined, SOME of the basenameTOC para formats in the generated
document have 'Across sidehead and all columns set' despite the fact
that these SAME para formats in the source document are set to 'In
column' like their sibling basenameTOC para formats, and

@ although the Right and Left master pages in the source have a sidehead
area, the body page in the generated filenameTOC.fm file do NOT!

What is even more baffling is that the generated filenameTOC.fm file has
an extra TOC1 reference page containing the default builders 

   <$paratext> <$paranum>

for the basenameTOC para formats.  There is also the EXPECTED TOC
reference page which is identical to that in the source document.

I have made sure that (a) all basenameTOC para formats are in the Para
Catalogue, (b) that on the TOC page, the basenameTOC para formats are
actually applied to their corresponding builder paras, and (c) the the
<numberformat> char format builder is applied to the appropriate parts
of the builder paras and is also in the Char Catalogue.

Saving to MIF and resaving to binary format does not fix. 
Reconstructing the TOC page does not fix.

Why has this horrible little imp been sent to continually revert my TOC
to some non-existent reference page and non-existent para and char
formats?  It's almost as though there is a phantom TOC page with
incorrect builders, para formats, and char formats that takes precedence
over the visible TOC page.  

I have wasted a couple of hours trying to fix this and am afraid there
is some simple explanation staring me in the face which I am too close
to and too overwrought to see.  What is maddening is that this technique
has worked reliably in the past on many different projects with many
versions of FM.

So Lee, Dov, Ed, Dan, Stuart, Tammy, Marcus x 2, Thomas x 2, Jeremy,
Shlomo, Bruce, Larry, and all the other heavy hitters, what's going on?

-- 
Yours, stuck in a mental rut,
Hedley Finger   Technical Writer

[FrameMaker 5.5.6, Acrobat 3.02, Windows 98, HP OmniBook 2100]

SUBSCRIBE TO THE ALTERNATIVE FRAMERS LIST
Message must consist of only this text (no signature, etc.): 
     subscribe framers <your@preferred.mail.address>
     help
     end
Send above message to: 
<mailto:majordomo@omsys.com?Subject=subscribe%20framers>

Ericsson Australia Pty Ltd
Tel. +61 3 9301 6214   Cell. +61 412 461 558   Fax. +61 3 9301 6199
Email. hedley.finger@ericsson.com.au

Hand Holding Projects Pty Ltd
Tel. +61 3 9809 1229   Cell. +61 412 461 558   Fax. +61 3 9809 1326
Email. hfinger@handholding.com.au

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **