Re: [Groff] Re: begin page blues

[Ted Harding]

On 21-Feb-06 Miklos Somogyi wrote:
> [...]
> I only have one philosophical question-mark. When I was a
> youngster (yes!), device independence and pre- and
> post-processors were good ideas and necessary.
> I wonder whether it still is the case.
> We, who got used to them, are comfortable with them.
> I'm not so sure about today's youngsters.
> Probably they would say that the dust has settled, Adobe won
> (whether they like this or not), so why concentrate on
> anything else than ps and pdf.
> And perhaps they would like a single application better,
> a groff with built-in tbl, eqn, me or mm etc, producing,
> say, only ps. I don't know, but sometimes it pays if one
> questions his/her whole approach As Time Goes By.

Interesting questions, and I have thought about them myself
from time to time.

On balance, I think the existing structure (pre- tbl, eqn,
pic etc.; post-devps etc.) works well in most cases and
gives flexibility.

There are certainly cases where one needs to call one or
more of the pre-processors in the "troff" phase of the
pipeline, and even interpose a "pre-post-processor between
the ditroff output of troff and the final post-processor.

Regarding in-line tbl, eqn, pic: This is needed when the
operation of the pre-processor depends on something which
can only be evaluated during the troff phase.

Examples include:

a) Computing the width of a box containing text in a 'pic'
   block. This can only be done using both the text itself
   and information about the font, the point-size, and the
   font metrics (e.g. with the "\w'text'" sequence), and
   the font and its metrics are unknown until troff looks
   at it; and the text itself may be dynamically generated
   during the troff phase.

b) Computing the values of numerical coefficients in an
   equation expressed in 'eqn' language, where these may
   depend on what is in some data file accessed by troff
   using ".so datafile"; also, the general numerical engine
   in groff is in 'pic' so as well as in-line 'eqn' you
   may need in-line 'pic' as well.

c) Similarly for 'tbl.

It is certainly possible to achieve (a), (b) and (c)
by using troff requests to write out lines to a temporary
file or files, use the ".sy" request to run 'tbl' or 'pic'
or 'eqn' on these saving the results to other temporary
files, and then using ".so" to read these results back in.

It can get quite complicated to set this up in some cases,
and it may be worth while encapsulating the procedure in
macros. This may look simple on the surface -- e.g. (in
outline)

.de pic
[open diversion]
..
.de /pic
[open temp file1]
[emit ".PS" to file1]
[write diversion to file1]
[emit ".PE" to file1]
[run pic on file1 writing to file2]
.so file2
..

and then, in-line:

.pic
[pic code using variables already defined]
./pic

-- but in practice one can find that it is not straightforward;
and it can be even less straightforward if you need to include
a call to ".pic" within a call to ".eqn", say.

However, I still think that such an approach is probably better
than embedding the functionality of the pre-processors within
the troff binary.

Nevertheless, I have to admit that this attitude may well be
a consequence of "youthful" experiences a long time ago, when
(as indeed now) this was the only way to do that sort of thing,
and once you have taken the trouble to work out how to do it
you develop a commitment.

Best wishes to all,
Ted.
[Leaning on his wooden ploughshare]

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 22-Feb-06                                       Time: 10:10:32
------------------------------ XFMail ------------------------------