[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Groff] tbl: pdf has wrong tables
From: |
Werner LEMBERG |
Subject: |
Re: [Groff] tbl: pdf has wrong tables |
Date: |
Thu, 27 Mar 2008 07:53:16 +0100 (CET) |
> > 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