groff
[Top][All Lists]
Advanced

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

Re: [Groff] LL Usage in an-old.tmac Incompatible with man Program on GNU


From: Keith Marshall
Subject: Re: [Groff] LL Usage in an-old.tmac Incompatible with man Program on GNU/Linux
Date: Sun, 14 Aug 2005 11:16:06 +0100

On Saturday 13 August 2005 5:34 pm, Werner LEMBERG wrote:
> > The `man' program, which I believe is currently used in the majority
> > of GNU/Linux distros, claims, as indicated by its own `manpage', to
> > adjust the displayed width of the formatted output to fit the width
> > of the console; it does this by injecting a `.ll' request into the
> > nroff input stream, [...]
>
> Hmm, my `man' program (version 2.4.1, 07 September 2001) uses this
> pipe for a wide screen:
>
>  sh -c (echo '.ll 132n'; /usr/bin/zsoelim /usr/X11R6/man/man7/X.7) \
>
>  | /usr/bin/tbl \
>  | /usr/bin/nroff -mandoc -mandocdb -rLL=132n -rLT=132n -Tlatin1 \
>
>  ...

You use Debian, right?  This uses `man-db', rather than `man'; but notice 
that it too attempts to inject a `.ll' request into the pipe.  This is 
presumably to satisfy non-groff implementations of `nroff', for which the 
accompanying `tmac.an' probably doesn't comprehend this `LL' usage; indeed, 
isn't the `-rLL=132n' incompatible with standard UNIX nroff?  (I'll check on 
the Solaris box at work tomorrow, to see what it's `tmac.an' does).

> Which man program do you use?

A search for `man' in the Free Software Directory, at 
http://directory.fsf.org, shows a first choice selection of a `man' 
implementation from ftp://ftp.win.tue.nl/pub/linux-local/utils/man/; the 
latest release of this, dated 2005-06-21, is version 1.6 -- I'm currently 
using version 1.5m.  I believe, although I may be wrong, that this is the one 
used by most Linux distros, other than those based on Debian, and it's also 
the one on which I've based my Win32 port for MinGW.

BTW, the `man-db' implementation used in Debian is the second choice 
selection in the FSF directory search; it's apparently maintained by Colin 
Watson of Debian.  The reference suggests that it is very definitely 
dependent on groff, whereas the primary `man' reference is intended to work 
with any troff/nroff implementation.

> groff_man.man says this:
>
>   -rLL=line-length
>      Set line length.  If this option is not given, the line length
>      defaults to 78n in nroff mode and 6.5i in troff mode.

And, of course I *could* add that to the nroff invocation spec in `man.conf', 
but that would still be a hard coded display width, rather than having the 
dynamically adjusted properties `man' tries to achieve with the `.ll' 
injection in the command pipe.

> > This used to work perfectly, with groff-1.17.x, but some recent
> > changes in an-old.tmac, (I'm not sure at which point it occurred),
>
> 2002-05-03 -- in the last three years there was no complaint...

Possibly because the displayed man page is still perfectly usable at the 
enforced width of 78 cols -- I was simply curious that none of the methods 
of adjusting the display width, advertised by `man', seemed to have any 
effect.

> > have broken this; specifically, the initialisations:
> >
> >     .ie n .nr LL 78n
> >
> >     .ll \\n[LL]u
> >
> > override the injected `.ll' request, forcing an output line length
> > of 78n, regardless of the width of the console display.
>
> This is the only way to provide a default width.

Accepted, but what's wrong with nroff's own default width?

> > Looking in an-old.tmac, it would seem that the LL register is mostly
> > redundant;
>
> I won't remove it -- I want orthogonality with other macro packages.
>
> > it is only ever used *once* in the above `.ll' initialisation, which
> > appears within the `TH' macro.  Thus, it could probably be dispensed
> > with altogether; however, if it is deemed worthwhile to retain it,
> > this patch will restore the behaviour expected by `man'...
>
> Thanks, but I won't apply your patch for the reason outlined above.

No problem -- I'll keep my patched version in site-tmac, so I can have the 
behaviour I want.

Best regards,
Keith.




reply via email to

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