Re: [Groff] moving TOC to start

[Keith MARSHALL]

>> After generating the reference dictionary, pdfroff then performs two
>> further passes, one to capture the table of contents into its own
>> PostScript file, the second to capture the document body text.
>
> Uh, oh, I wasn't aware that you use this indeed very nasty strategy
> within pdfroff...

Yes.  It was a Q&D workaround, to get a working prototype -- I never
liked it, not even a little bit, and certainly never intended that it
should stay that way.  I even noted, in the script, that the piece of
code to do it was a hack; I should probably also have flagged it as a
`FIXME'.

> ...  As Tadziu suggested in another mail, groff should
> behave like LaTeX (and I was incorrectly assuming that the ms macros
> already do something similar), this is, writing out the table of
> contents piece by piece into a separate file so that the created
> auxiliary file can be read in by a second pass at any location.

No.  The `XS', `XA' and `XE' macros collect the TOC entries into a
diversion, which is flushed when `TC' is called; to cover the entire
document, this has to come at the end.  This is the way `ms' has
always worked, both in groff and traditional troff implementations;
I believe `mm' also handles TOC entries similarly, although, having
never used it, I could well be mistaken.

> This
> not only fixes the nasty collation problem, it also fixes possible
> page numbering issues -- it even allows that the table of contents
> ends on the same page as the main body starts (this may be useful for
> mini TOCs which are located at the beginning of each chapter, listing
> the sections and subsections to come).

I can certainly see the advantages of this approach -- it does however
place an additional burden on either the document author, or the author
of some additional macro package, to manage the details.  I can equally
see merit in the approach I proposed, assuming that the required internal
modifications to groff to provide the collating mark capability wouldn't
be too onerous, (and I don't believe that they would be).  The details
of ordering the final output would then be handled by a standardised
external program, and document or macro package authors could control
the final document layout by simply placing collating mark references,
with appropriately ranked indices, into the document data stream; (I
see this working in a similar fashion to the collating mechanism of
`m4' diversions).

If you don't see any point in pursuing this, I won't take it any further;
at this stage, I just wanted to kick the idea about a bit, to see what
others thought of it.

Best regards,
Keith.