![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> If you send your nroff input file to the RFC editor as well as the > nroff'd output file, which is the recommended practice, then modifying > the ms macros themselves is not an option. Well, sort of. You can .rm an existing macro and .de it differently. I do that for the SH, H, XS, XA, XE, XE and TC requests, then use soelim to put my macros into the nroff source I send to rfced. So far no feedback from that quarter, positive or negative. > Automatic TOC processing cannot be done directly within nroff unless you > are willing to accept the TOC at the end of the document. To place the > TOC at the beginning of the document usually requires two passes. The > first pass is used to generate the TOC, which is then sourced (.so'd) > into the document for the second pass. That's the LaTeX-like way. What I do is start a draft-with-TOC with .so tmac.idt .pi ./fixtoc.sh where fixtoc is Postel's fix.sh with the added function of moving the TOC from the end to a marked point near the front. Matt (But the fun part was computing the six-months-plus-five-days expiration date in nroff.)
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.