Re: [Groff] grog Using groff.

[Ralph Corderoy]

Hi Werner,

Thanks for the answers.

> > grog, old and new, produces a groff command making use of its -p,
> > -t, etc., options to pull in all the pre-processors.  The doctype
> > script from Kernighan and Pike's _The Unix Programming Environment_
> > which influences it produces
> > 
> >     cat "$@" | refer | pic | ideal | tbl | eqn | troff -ms
> > 
> > What advantages does grog have of using groff?
> 
> It's easier to read for humans, and it handles the output device.
> Think of the complicated command line for `groff -Thtml'.

OK.  I agree.

> > Alternatively, groff could have another option that speficies a
> > pre-processor to add to the pipeline.  Then grog could produce
> > 
> >     groff -? ideal -pt -ms
> 
> This sounds like a nice idea.  Perhaps two switches: one to put a
> preprocessor as the first into the queue, and another to make it the
> last. Using the switches more than once should be possible, retaining
> the order given on the command line.

I don't think that would be sufficient since groff `knows' the best
order of -pte regardless of which order you give the options in, e.g.
-etp.  So although you might say

    groff -prefix foo -p -suffix bar -t

AFAICS you wouldn't end up with

    foo | pic | bar | tbl

> > but how would groff know the best order to put the pre-processors
> > in, i.e. where to place ideal in the pipeline it would otherwise
> > build?
> 
> But grog has exactly the same problem, hasn't it?  How does grog know
> the right order?

grog doesn't have the same problem for the same reason groff doesn't
have the problem at the moment.  groff knows about all the preprocessors
and their ideal order -- it's coded into it.

    const int SOELIM_INDEX = 0;
    const int REFER_INDEX = SOELIM_INDEX + 1;
    const int GRAP_INDEX = REFER_INDEX + 1;
    const int PIC_INDEX = GRAP_INDEX + 1;
    const int TBL_INDEX = PIC_INDEX + 1;
    const int GRN_INDEX = TBL_INDEX + 1;
    const int EQN_INDEX = GRN_INDEX + 1;
    const int TROFF_INDEX = EQN_INDEX + 1;
    const int POST_INDEX = TROFF_INDEX + 1;
    const int SPOOL_INDEX = POST_INDEX + 1;

Add a preprocessor groff doesn't know about using some new command line
option and it doesn't know where to place it.  grog also knows about all
the things it can heuristically (stop sniggering Scovell) spot and could
also have their ideal order coded into it.

> Perhaps I should add three more switches for `ideal', `chem', and
> `dformat' to assure the right position.  Are there still other
> preprocessors out there?

I think that's the worst solution.  We'd end up like ls(1)  :-)  There
will be others out there, e.g. G3.  groff -T and -m options are much
superior in that they take a parameter.

> > BTW, can there be any problems caused by running soelim
> > unconditionally?
> 
> AFAIK, no.  There are sometimes situations where .so should be
> recognized by groff but not by soelim; the solution is to write `. so'
> which isn't recognized by soelim.

Good.  grog doesn't recognise anything but `.so' either.

The only idea I have at the moment is to have groff associate a number
with each stage of the command line to define the order, and the new
command line option would be able to specify the position with a
--long-opt to list all of groff's built in ones.

    $ groff --long-opt
     100 soelim
     200 refer
     300 grap
     400 pic
     500 100 tbl
     600 grn
     700 eqn
     800 troff
     900 post
    1000 spool
    $ groff -? g3 350 -p

Not great, but then grog and groff are both in the business of hiding
the yucky stuff from the user.


Ralph.