On Wednesday 17 August 2005 4:22 pm, Werner LEMBERG wrote: > > 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). > > Hmm, it's not incompatible, but classical troff doesn't have -r, so it > should be ignored.
If this were true, I would expect classical troff to choke on an `illegal option', rather than to simply ignore it. However, as Tadziu has already pointed out, classical troff does support `-raN', where `a' is a single character register name, but it does not support groff's extended syntax, which allows for arbitrary length register names. Thus, classical troff will interpret `-rLL=132n', for example, as an assignment for a register named `L', with a value of `L=132n', which is unrecognisable as a numeric value, and so becomes zero. In this sense, the `-rLL=132n' syntax is incompatible with classical troff, since it is not interpreted as intended, or indeed, as one might expect. This is in no way intended as a criticism of groff's extended syntax, which IMO is perfectly natural and obvious; it is merely an observation that such extensions, while being beneficial, do require us to sacrifice backward compatibility. > > > > .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? > > groff's nroff use the same default width as all other devices, namely > 6.5i, which is 65 columns. IMHO it's the job of the macro package to > set a suitable default width (as does -ms, for example). A reasonable opinion, but does it need to be quite so cavalier about it, as the current implementation appears to be? > > > > 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. > > BTW, I've looked into the Solaris `an' macro file and found this in > the `TH' macro: > > .ll 6.5i > .nr LL \\n(.l > > This basically means that you can't modify the width of man pages. > Does `man' on Solaris really adjusts the width of man pages to a > changed terminal width? Yes, I found the same. And no, Solaris' `man' doesn't vary the display width to suit the screen -- quite irritating, IMO, when half the width of a wide screen is wasted by text constrained to a 65 character width. > > No problem -- I'll keep my patched version in site-tmac, so I can > > have the behaviour I want. > > It might be a good idea to report this to the `man' maintainers so > that they can insert a proper `-rLL=...' call similar to `man-db'. I just merged Federico Lucifredi's man-1.6 release into my MinGW ported codebase -- quite easy, with the help of CVS :-) I notice that this now injects a `.nr LL ...' request into the pipeline, to achieve the same effect. However, this release is too new -- less than two months old -- to have made it into any current distro, so there may yet be justification for adding some form of backward compatibility support for earlier `man' versions into groff. I fully respect your right to reject any patch, and your reasons for doing so in this case, but would you consider a variation, accompanied by a manpage update, implementing the following behaviour?: - If the LL register is defined, prior to the invocation of TH, then honour its setting -- this is exactly as current behaviour, and would take precedence over any other line length initialisation method. - If LL is not defined, but a prior `.ll' request has changed the line length from the nroff/troff default, then initialise LL to match the adjusted line length -- this would be an extension to present behaviour; it would be effective only if the value of \n[.l] differs from the nroff/troff default, at the time when TH is invoked, and could be restricted to apply in nroff only, but probably makes sense to allow it for troff as well. - If neither of the above applies, then initialise LL to 78n for nroff, or 6.5i for troff, exactly as present behaviour. If this would be accaptable, I can provide a suitable patch. Best regards, Keith. _______________________________________________ Groff mailing list [email protected] http://lists.gnu.org/mailman/listinfo/groff
