RE: [Groff] Page classes in groff output to support reordering o

[T. Kurt Bond]

(Ted Harding) writes:

[a very interesting and thorough discussion of the way DSC page labels
are created in postscript output by gtroff and grops.]

> Possibly the most straightforward mechanism would be to extend the
> \X'ps: ...' mechanism (with corresponding implementation code in
> grops).

Actually, I think something like this could be useful for all the
output backends for reordering.

> In that case, the following suggestions seem to me to be feasible:
> 
> 1. A new \X'ps: ...' command like
>    \X'ps: pagenumformat F' where F may be as in troff .af, namely
>    1 001 i I a A
> 
>    This would at least require the void ps_printer::begin_page(int n)
>    function (above) to be re-written so that the formatting of n
>    is done by a different routing (capable of achieving format F)
>    instead of itoa(n).
> 
> 2. A new X'ps: ...' command like
>    \X'ps: pagelabel F text' where F is as above and "text" is
>    whatever the user wants (e.g. TOC, Author Index, Bibliography ... ).
>    This could presumably be used instead of or in addition to the
>    suggestion in (1).
> 
>    This would require an additional re-writing of the function
>    ps_printer::begin_page(int n) to be something like
>    ps_printer::begin_page(int n, char *F, char *text)
>    with appropriate support code.
> 
> Meanwhile, I think for practical purposes it should not be too
> difficult to simply do what you are now doing, namely determining
> independently what page-numbers correspond to the different classes,
> and using say pstops to extract these when the page-list is submitted
> via an argument to pstops.
> 
> However, you have raised an interesting and by no means entirely
> cosmetic issue about groff. It would be good to see other users'
> comments on these questions.

The difficult thing to do automatically is to figure out where things
like the table of contents start and stop, so you can move them to the
beginning.  Since the user can do things like

    .bp 1
    Some random text here.
    .bp 10
    Some other random text here.
    .bp 1
    Yet more random text here.

you can't just have the macro package record the pages where the table
of contents started and ended, since other pages might have the same
page number.

It might be useful if gtroff had a predefined read-only number
register, say \n[.pp] (for physical page), that recorded the physical
page number independent of what \n% had.  This number would start at 1
and be increased by 1 at the start of each new page, regardless of
what the user has requested with .bp or .pn.  The "p" command in
gtroff output could be followed by something like

    x X page: 1 i 3

where "1" is the page number from \n%, "i" is the page number
according to the current current format for % requested by .af, and 
"3" is the physical page of the document.  (In this case, there was a
cover page and a copyright page before the table of contents started
on logical page "i", physical page "3".)

The macro packages could use this physical page number to uniquely
identify where a section starts and stops and reordering packages
could depend on it.

Reordering filters could operating on these 'x X page:' commands,
while grops could generate DSC comments from them for the postscript
otuput.  Other postprocessors could ignore them.

If macro packages were to output at the start of a new document part
something like

    x X part: cover
    x X part: body
    x X part: appendix
    x X part: TOC
    x X part: LOF
    x X part: LOI

a reordering filter could automatically reorder the output into a
user-specified order, perhaps like this:

    $ gtroff -ms input.ms | 
         reorder --order=cover,TOC,LOI,LOF,body,appendix |
         grops >output.ps

The grops postprocessor could use that to make DSC comments like
"%%Page: TOC-i 3" or "%%Page: BODY-1".

If gtroff had a writable predefined string, perhaps \*[.sect], 
that started out blank and was always output after the "p" command for
each page as the end of a "x X part:" command, the macro packages
could just set this and each page would be labeled, which would make 
reordering and labeling simpler for the postprocessors, at the expense
of more complication in gtroff.

I don't know if others would find these useful, but it's certainly
interesting to think about.
-- 
T. Kurt Bond, address@hidden