>> 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. _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff
