Re: [Groff] tbl: pdf has wrong tables

[Werner LEMBERG]

> > I have problem convert manual page ps1.1 from manual to pdf or ps
> > file.  The pdf file has tables over the edge of the paper.  I'm
> > using groff-1.18.1.4.
> 
> I haven't looked at generating PDF yet, but ps.1 formats badly to a tty
> on this Ubuntu 7.10 system.  Perhaps that suggests it's not PDF
> generation that's the problem but the column width settings in the ps.1.
> 
> ~~~~~~ 80 character line length 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>        args    COMMANDcommand with all its arguments as a string. 
> Modifications
>                       to the arguments may be shown. The output in this column
>                       may contain spaces. A process marked <defunct> is partly
>                       dead, waiting to be fully destroyed by its parent.
>                       Sometimes the process args will be unavailable; when 
> this
>                       happens, ps will instead print the executable name in
>                       brackets. (alias cmd, command). See also the comm format
>                       keyword, the -f option, and the c option.
>                       When specified last, this column will extend to the edge
>                       of the display. If ps can not determine display width, 
> as
>                       when output is redirected (piped) into a file or another
>                       command, the output width is undefined. (it may be 80,
>                       unlimited, determined by the TERM variable, and so on) 
> The
> ~~~~~~ 80 character line length 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I don't get this.  For me, it looks like this if formatted with

  groff -t -Tascii -man

================================================================================

args       COMMAND  command with all its arguments as a string. Modifications
                    to the arguments may be shown. The output in this column
                    ...
================================================================================

with either groff 1.18.1 or the current CVS.

However, Marcela's problem lies elsewhere: If you compile the table
with -ww for -Tps you can see that groff emits a bunch of `numeric
overflow' warnings.  This strongly indicates that the computation of
\n[ColSize] is wrong.  In ps.1, you can find this:

  .\" ColSize is used for the format spec table.
  .\" It's the left margin, minus the right, minus
  .\" the space needed for the 1st two columns.
  .nr ColSize ((\n(.lu-\n(.iu/\n(.Hu-20u)n)

For better readability, I'm rewriting it as

  .nr ColSize ((\n[.l]u - \n[.i]u / \n[.H]u - 20u)n)

Two serious errors are in this computation:

  . You can't apply the `n' scaling indicator to an expression in
    parentheses but only to something which immediately expands to a
    number.  Consequently, for -Tps, \n[ColSize] is far too large.

  . Dividing by \n[.H] is completely wrong to convert from `u' units
    to `n'.  A simple division by `1n' does the trick.

Rewriting it as

  .nr ColSize ((\n[.l] - \n[.i]) / 1n - 20)

makes the problem disappear.  Some table entries are still badly
formatted, because the width of the first two columns are based on `n'
units instead of computing the width of the widest entry with \w'...'
(or even better, letting `tbl' do this automatically).


    Werner