Re: [Groff] Passing -D argument to grap on groff command line?

[Ted Harding]

On 21-Sep-06 Werner LEMBERG wrote:
> 
>> I realize that it is possible to use the environment variable
>> GRAP_DEFINES to pass the name of the grap definition file to grap,
>> but I'd really like to be able to do this from the groff command
>> line.  How do I do this?  The groff "-P" option seems to pass
>> arguments on to postprocessors only.
> 
> Indeed, groff has no ability to pass arguments to preprocessors, even
> for the ones which come with the groff bundle.  For eqn, to name an
> example, Clarke's solution was to add configuration support directly
> into the document via a special first .EQ ... .EN section.  Maybe
> something similar exists for grap also?  Otherwise, you can pass the
> environment variable directly on the command line:
> 
>   GRAP_DEFINES=foo groff ...

Following up Werner's comment above (and bearing in mind Ted Faber's
follow-up), I've long used a similar approach with pic. Thus, one
can carry out preliminary calculations, and read in external files
with 'pic' code, like

.PS
pi = 4*atan2(1,1)
copy picdefs.pic
.PE

and, so long as no graphically oriented output is required by this,
pic will
a) suppress the ".PS" and ".PE",
b) output only a couple of ".lf" requests.

Therefore such an interpolation in the troff source file will have
no effect whatever in the final output, not even a line break, no
matter where it occurs.

I think it was not always thus -- I certainly have a "customised"
version of ".PS" and ".PE" (dating from long ago) available in ms
macros, which recognise an extra argument "T" (for "tacit"), so
that I can write

.PS T
stuff that will not draw anything
.PE

with the effect that when the ms macro ".PS" sees "T" it suppresses
any normal action of ".PS" and ".PE", in effect rendering them null.
In recent versions of pic this does not seem to be needed, as
explained above.

However, if you do something similar with ".EQ" and ".EN", then
even if no equation formatting is to take place eqn will still
output the ".EQ" and ".EN" and output some stuff, with the effect
that you at least get a line-break and possibly some spacing,
depending on how ".PS" and ".PE" are implemented in the macro
package.

For example,

This is some text.
.EQ
define r2p %sqrt{2 pi}%
.EN
This is more text.
.EQ
{{roman e} sup {- half x sup 2}} over r2p
.EN
This is even more text.

causes a break between "This is some text" and "This is more text".
The relevant part of the output of eqn is

  This is some text.
  .EQ
  .nr 0C \n(.C
  .cp 0
  .ds 10
  .cp \n(0C
  .lf 7
  .EN
  This is more text.

which, in this context, in fact does nothing effective.

This may not matter when ".EQ ... .EN" is called at the very start
(as in reading in the eqnrc, or when user-planted), but there may
be cases where the user wants, perhaps, to redefine something in
the middle of a document (without doing anything else), and the
current behaviour of eqn would have an intrusive effect when none
is needed.

I don't know how this issue is treated in ".G1" and ".G2", since
I have not used gremlin.

In any case, I think that the current behaviour of pic, as
described above, would be desirable for all preprocessors
where it may be needed to interpolate code in the troff source
to cause them to do some work which would not generate printed
output, for the sake of later calls which will generate printed
output that depend on this work.

(I don't think this consideration can apply to tbl, however,
since there's nothing in the way of "preliminary work" you can
do which would apply to a subsequent ".TS ... ".TE").

Best wishes to all,
Ted.

--------------------------------------------------------------------
E-Mail: (Ted Harding) <address@hidden>
Fax-to-email: +44 (0)870 094 0861
Date: 21-Sep-06                                       Time: 17:04:55
------------------------------ XFMail ------------------------------