On 20-Aug-08 17:47:47, Tadziu Hoffmann wrote:
>> The following does not come out as I would expect
> [snip]
> After a bit of experimentation (use option "allbox" to make the
> widths visible) I believe the behavior can be explained as
> follows:
>
> For calculating the cell widths, all cell contents are inspected
> *independently*. Thus, the apparently longest line ("Let her
> fame spread far and wide") does not see the "\s[18]" of the other
> cell and is therefore assumed to be at the default point size,
> and the width of the cell is computed accordingly. On output,
> however, the individual cells are not sandboxed, so the "\s[18]"
> stays in effect, leading to the "strange" appearance.
Excellent detective work, Tadziu! Thank you very much.
In view of your conclusions, I tried setting the point-size in
the column specifiers (to force tbl to know the font-size), and
this worked:
.LP
.TS
centre tab(#);
cp24.
\fBZIMBABWE\fP
.T&
cp28.
\f[BI]Translation\fP
.T&
lp18.
God bless Africa,
Let her fame spread far and wide
Hear our prayer:
May God bless us!
Come, Spirit, come!
Come! Holy Spirit!
Come and bless us, her children!
.TE
This produced exactly what I want. There is an underlying issue
remaining, however, which may be worth thinking about.
Namely: tbl often has to cope with stuff that no-one can know
the length of until troff has finished with it. In particular,
equations entered using things like ${x + y} over {u + w}$.
Now, tbl does have a mechanism for creating number-registers
which will be evaluated by troff, precisely for this kind of
thing. So I'm wondering why this did not come into play here!
Thanks again!
Ted.
--------------------------------------------------------------------
E-Mail: (Ted Harding) <[EMAIL PROTECTED]>
Fax-to-email: +44 (0)870 094 0861
Date: 20-Aug-08 Time: 19:11:49
------------------------------ XFMail ------------------------------
