FM TOC reference page generation

[Wes Edmonds]

Is there a way to force FM to use a document's modified TOC reference page instead of it generating a second one when creating a separate TOC file?

[Arnis Gubins]

FM uses the content of the *first* flow labelled "TOC" on the  Reference pages of the TOC file (not the source files). The Reference page name is only for convenience.

[Art Campbell]

Wes, could you go into more detail about your situation?

In the plain vanilla scenario, the TOC would be generated by the TOC's Reference Page setup.

But apparently that's not hapening in your case. This may happen when a second TOC is added to a book, or you make mods to the Ref Page that aren't supported.

But you didn't provide a lot of detail, so it's hard to trouble-shoot.

Art

[Wes Edmonds]

I modified the TOC reference page of the document I completed as follows:

openXmlElementId <$relfilename>:<$UniqueXmlElementId> <$RelativeXmlElementId>

openObjectId <$relfilename>:<$ObjectType> <$ObjectId>

<$elemtextonly>

       <$paranum>\t<$elemtextonly> ......................................................................<$pagenum>

            <$paranum>\t<$elemtextonly> .................................................................<$pagenum>

                    <$paranum>\t<$elemtextonly> .........................................................<$pagenum>

                    <$paranum>\t<$elemtextonly> .........................................................<$pagenum>

Each of these lines is formatted with its own Paragraph Tag (ie. Pgblk()TOC, Task()TOC, etc) which are Tahoma, 10pt.

When I generate a standalone TOC clicking [Special] >Table of Contents... > [Yes] (Do you want to creat a standalone TOC for this doc?), the new standalone TOC will not look like I expect and in the reference pages and I will have a second TOC ref page named "TOC1" with the following code:

<$elemtextonly> <$pagenum>

openXmlElementId <$relfilename>:<$UniqueXmlElementId> <$RelativeXmlElementId>

openObjectId <$relfilename>:<$ObjectType> <$ObjectId>

<$elemtextonly> <$pagenum>

<$elemtextonly> <$pagenum>

<$elemtextonly> <$pagenum>

<$elemtextonly> <$pagenum>

Each of these lines are in default Times New Roman font, 12pt and seems to be what FM uses to generate the TOC instead of my modified reference page from the original doc.

[Van Kurtz]

I do not know the answer to your specific question about the two TOCs, but a workaround would be to format the second TOC to match the first one. Then Frame can use whichever it likes...and hope it does not create a third TOC.

Van

[peter minneapolis]

Wes Edmonds wrote:

I modified the TOC reference page of the document I completed as follows:

openXmlElementId <$relfilename>:<$UniqueXmlElementId> <$RelativeXmlElementId>

openObjectId <$relfilename>:<$ObjectType> <$ObjectId>

<$elemtextonly>

       <$paranum>\t<$elemtextonly> ......................................................................<$pagenum >

            <$paranum>\t<$elemtextonly> .................................................................<$pagenum>

                    <$paranum>\t<$elemtextonly> .........................................................<$pagenum>

                    <$paranum>\t<$elemtextonly> .........................................................<$pagenum>

Each of these lines is formatted with its own Paragraph Tag (ie. Pgblk()TOC, Task()TOC, etc) which are Tahoma, 10pt.

When I generate a standalone TOC clicking [Special] >Table of Contents... > [Yes] (Do you want to creat a standalone TOC for this doc?), the new standalone TOC will not look like I expect and in the reference pages and I will have a second TOC ref page named "TOC1" with the following code:

<$elemtextonly> <$pagenum>

openXmlElementId <$relfilename>:<$UniqueXmlElementId> <$RelativeXmlElementId>

openObjectId <$relfilename>:<$ObjectType> <$ObjectId>

<$elemtextonly> <$pagenum>

<$elemtextonly> <$pagenum>

<$elemtextonly> <$pagenum>

<$elemtextonly> <$pagenum>

Each of these lines are in default Times New Roman font, 12pt and seems to be what FM uses to generate the TOC instead of my modified reference page from the original doc.

I remember having this happen a few years ago, probably in FrameMaker 7.x, perhaps 6.x. I can't remember ever finding its cause, or a remedy that avoids it. A quick Google search today didn't reveal the secret fix, though, I didn't dig deep into the results.

My solution was to import the TOC formats into the TOC<#> from either the document set's TOC template, or the main TOC document itself. This should fix the page layouts and text properties, but will not change the page references, etc., so the reformatted TOC should be what you expect.

An alternate approach is to create a copy of the TOC template in the directory where the chapter TOC will be created, name and save it to the TOC<#> that you anticipate will be generated. IIRC, generating the chapter TOC will fill the anticipated TOC with correct information formatted correctly.

Another option is to create a container TOC document with the correct formatting and import the generated TOC into it - this depends on having a version of FrameMaker that can import FM files.

HTH

Regards,

Peter

_______________________

Peter Gold

KnowHow ProServices