[Top][All Lists]

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

Re: [Groff] Heirloom TBL problem

From: Blake McBride
Subject: Re: [Groff] Heirloom TBL problem
Date: Mon, 22 Jun 2015 09:02:16 -0500

I have been using troff on and off since 1983.  I know all that.

The macro packages act as a higher level API but almost never completely
duplicates all of the lower level commands.  Surely you don't want to
conflict with a macro package that assumes it has control over a certain
parameter, but likewise one must use the lower level API when attempting to
do something the macro package had no need to encapsulate.

A.  MM has no clear way to set ll

B.  Tbl clearly understands ll with MM in groff, and it makes sense.


On Mon, Jun 22, 2015 at 7:32 AM, Mike Bianchi <address@hidden> wrote:

> On Sun, Jun 21, 2015 at 08:35:34PM -0500, Blake McBride wrote:
> > On Sat, Jun 20, 2015 at 3:52 PM, <address@hidden> wrote:
> > > The interface to .ll is \nW or .PGFORM.  At first my plan was to
> implement
> > > .PGFORM.  But *maybe* using W like MS's LL could also make sense.  But
> for
> > > compatibility with groff .PGFORM should be prefered. (?)
> >
> > Adding .PGFORM is fine, but I would prefer just having .ll work like it
> > does on groff.   This way the original docs work and produce as expected.
> Asking for  .ll  to work like it does in groff is an oximoron.  The
> commands
> documented in  groff(7)  are the assembly language of groff.  They are the
> commands on which all extensions to groff are built.
> So when you use the MM or MS macros, you are using extension macros that
> are
> built on the groff commands.  Likewise, programs like tbl(1), eqn(1),
> pic(1),
> etc. process the input and emit the input combined with more groff commands
> that groff then processes to create the desired outcomes.
> Most macro packages, and certainly MM and MS, have preferred ways of
> specifying
> line length that ultimately emit  .ll  commands to implement the desired
> results.
> Using the groff commands within other macro packages often produces
> confusing
> and unexpected results.
> So the recommended practice is to stick strictly to the "higher-level"
> macros
> of the macro package, or packages, you are using.
> Mixing the package macros with groff macros is discouraged, except to those
> who imagine themselves to be experts in groff _and_ the macro packages.
> I am one such person, and have many sad tails to tell of my ignorance.
> --
>  Mike Bianchi
>  Foveal Systems
>  973 822-2085
>  address@hidden

reply via email to

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