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

[Bernd Salbrechter]

Hi all!

Thanks for the interesting replies and sorry for my late answer,
but I was really busy last week. It looks like I have start an
interesting discussion for groff. I will post a summery of the
answers I got and clarify some points.

1. It looks like it will be a good idea to put a reordering of
pages (based on the logical parts) between groff and the post-processors
(i.e. grops). Because this can be useful for all output formats.

address@hidden (Larry Jones) (24 Jul 2000):
> address@hidden writes:
> > 
> > 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
> 
> I think this is too restricted in scope to be useful.  What you really
> want is a way to communicate the user-visible page number to any back
> end, not just grops.  And the user-visible page number can be quite
> complex: "2-1", "Index 2", "2.3", etc., so I think it needs to be a
> string, it needs to be something that a macro package can do (since each
> macro package formats page numbers differently), and it needs to be
> device-independent.

T. Kurt Bond <address@hidden> (22 Jul 2000):
> While it might not work in the completely general case (multiple
> resized logical pages per physical sheet), I can't see why it wouldn't
> work for moving the table of contents and such around.  It looks like
> in gtroff output the "p" command that starts a new page is always
> followed with an "f" command to set the current font, so the pages
> should be fairly independent.  And doing this in a filter between
> gtroff and the device-specific post-processor would allow this
> reordering to be done independently of the type of final output
> device, so it would be useful not only for grops, but also grodvi,
> grotty, grolj4, and grolbj.

Yes thats the real point her, it can be done easily for all
output formats, which support comments (i.e. PostScript) but would
be quite difficult, if not impossible for less powerful output formats
like ASCII. And it wast of resources to implement it for each output
format.

> Geoff's output, with one command per line, is well suited for this;
> some di troff descendants (Unixware's, I think), on the other hand, put
> multiple commands on one line, delimited only with whitespace, which
> makes it harder.
> 
> True, but the common, indeed very common, desire to put the table of
> contents, etc., into the proper place  in the document, seems to me to 
> be very practical and useful.
>
> The user would still have to indicate in some manner how where the
> table of contents starts and ends, but this could be done
> automatically by the (suitable modified) macro package, or manually.
>
> Actually, I think something like this could be useful for all the
> output backends for reordering.

2. groff need a clear and well defined interface from the macro
package to the post-processor to pass the information to which
logical part a page belongs.

address@hidden (Larry Jones) (24 Jul 2000):
> T. Kurt Bond writes:
> > 
> > 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.
> 
> I think something along these lines is definitely needed, but I want to
> caution against tying it to \n% too strongly -- many macro packages use
> their own register(s) and/or string(s) for the page number and
> completely ignore \n%, so you need a mechanism that the macro package
> can use to communicate the information rather than building something in
> to groff that isn't modifiable.

The interface must work with macros that relay on the \n% and such
that maintain there own registers for page numbering. If I am right
the user (macro package) sets the number of the next page with
".pn" with the page number as parameter. Wouldn't it be nice to have
an additional optional parameter to identify the logical part (I
would vote for a string). Is \s% free for that purpose? If the
macro package maintain there own registers for page numbering, it
must set a defined string variable (\s% ?) to pass the information
to the post-processor. Or should there be a total new request for
that?

Now a short overview on the processing I plan to do.

  groff --page-format=A6 doc.roff | \
  new-reorder | \
  grops | \
  new-ps-imposition --imposition=A6-A3-perfect-bound doc.ps | \
  lpr

I have marked tools not existing now with "new-". If reorder doesn't
exist I can use pstops on the PostScript output. A full imposition
will only work on reasonable powerful output formats like PostScript
(my be dvi, there are dviutils!) and should never be mixed with
the reordering we discuss here.

As you can see groff and new-ps-imposition need a common understanding
on the dimension of paper formats. I have noticed that groff now uses
libpaper to get that information. I looked into libpaper (thanks
for that pointer to it a year ago) and I say it's not a solution
to that problem, but it's better than before. A real solution, will
be to pull the information on the dimension of the paper formats
out of the programs into a database. I have started paper capability
database (like termcap and in the same format) with micrometer as unit
and a maximum paper size of about 4 km in square (range of a 32 bit
number).

Bernd

PS.: I will be on vacation for 3 weeks. But will try to get time
for this after that.

PPS.: If you think the TeX people can contribute or benefit from
this discussion, feel free to forward it there.