[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: T. Kurt Bond
Subject: RE: [Groff] Page classes in groff output to support reordering o
Date: Sat, 22 Jul 2000 15:09:23 -0400 (EDT)

On 20-Jul-00 Bernd Salbrechter wrote:
> In more detail the idea is to use groff to format a document into
> well layouted pages (groff do this job quite well) and use the
> pstools [he meant psutils] to put may of that pages onto one sheet
> of paper, which get folded, stitched and trimmed to get nice
> booklets. The "pstools" need some improvement at least for no so
> common impositions like gate fold, concertina fold or 8 pages on one
> sheet of paper and a 64 page signature.

(Ted Harding) writes:
> In my view it is probably not a good idea to try to incorporate this
> kind of thing into groff itself. 

I agree that the re-ordering itself should not be done in the gtroff

> The way the main engine (gtroff) works is strictly sequential and
> pages get formatted as they are encountered, so it would need to
> take place either as a modification of the grops post-processor, or
> in an extra post-processor placed between gtroff and grops or
> following grops. The last case is, in effect, what you are trying to
> do with pstools.

> Putting an extra post-processor between gtroff and grops would probably
> not work, for all sorts of reasons, 

Could you expound on these reasons?  I've actually used a
simple-minded version of this to re-order pages in troff output.

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.

Groff's output, with one command per line, is well suited for this;
some ditroff descendants (Unixware's, I think), on the other hand, put
multiple commands on one line, delimited only with whitespace, which
makes it harder.

For those who haven't looked at gtroff's output format before, it is
documented in the revised version of the Nroff/Troff manual

    CSTR #54, J. F. Ossanna, Nroff/Troff User's Manual, Bell Labs,
    1976. Revised by Brian Kernighan, 1992.

in section 22, with groff's additions documented in groff_out(5).

> and similarly for a modification
> of grops which was not equivalent to a post-processor following grops.
> Furthermore, once you contemplate re-ordering pages for special purposes
> there is no limit to the possible variations you may need to consider.

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.

T. Kurt Bond, address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]