Re: [tbl] Line wrapping (Was: Setting the widths of the columns)

[G. Branden Robinson]

At 2023-04-29T16:04:28+0200, Frederic Chartier wrote:
> On 2023-04-28 16:39 -0500, G. Branden Robinson wrote:
> 
> > Per tbl(1) from groff 1.23.0:
> > [...] 
> >     Ordinarily, a table entry is typeset rigidly.  It is not filled,
> >     broken, hyphenated, adjusted, or populated with additional inter???
> >     sentence space.
> 
> This sentence was added in version 1.23, wasn't it ? This point
> needed to be emphasised.

Yes--I thought it important, too, which is why I added it.

> One thing about tbl that threw me earlier this week was its attitude
> to line wrapping.
> 
> Call me crazy, but I expected that tbl would by default do whatever it
> takes to make the table fit in the available horizontal space.

I think that's kind of an HTML-ish approach.  On typeset documents it
can be as important, or more so, to be able to predict the amount of
vertical space on the page a table will consume.  A text block is an
explicit acknowledgement that some vertical expansion will occur.

Also worth noting is that tbl _will not_ permit a page break within a
table row.  This can be a deficiency for some multi-page tables I've
seen in technical books (laid out using Microsoft Word, maybe), where
you have huge, gray-shaded tables with immensely tall cells.

On the other hand, I find such tables as I have seen difficult to manage
as a reader, particularly when they omit the column headings on
subsequent pages and leave multiple columns entirely blank for one or
more pages at a time.  Such specimens might, in many cases, simply be
the result of the author making do with the layout facilities that Word
offers.  tbl insists on being able to set a text block in its entirety
on a single page, even if it has to break the page before _and_ after.
This constraint might discourage objectively bad table layouts.

> There are no scroll bars on a piece of paper.

Right.  I think that fact militates in favor of tbl's approach.

> I also assumed that "T{" ...  "T}" was purely a syntactic device,
> Troff's counterpart to here-documents. It took me a while to
> understand that "T{" has another, unrelated function : it's the secret
> password to make tbl wrap text.

Yes.  The term "text block" was present, but less emphasized, in past
versions of groff.

> Neither the original tbl papers nor the book "Unix text processing"
> went out of their way to point out these IMO very non-obvious facts.
> (Or if they did, it was too subtly for me to notice.) I don't know if
> Groff's tbl(1) is quite there yet but it seems headed in the right
> direction.

Thanks!  What is your opinion of the point Ralph raised?  Is the matter
of the interactions of the 'w', 'e', and 'x' modifiers belabored?

Here's how tbl(1) in groff 1.22.4 (and 1.22.3) put the issue:

       The  column specifier x is mutually exclusive with e and w (but
       e is not mutually exclusive  with  w);  if  specified  multiple
       times  for  a  particular  column, the last entry takes effect:
       x unsets both e and w, while either e or w overrides x.

And here's what groff 1.23.0's tbl(1) says:

    ... If the same modifier is applied to a column specifier more than
    once, or if conflicting modifiers are applied, only the last
    occurrence has effect.  The modifier x is mutually exclusive with e
    and w, but e is not mutually exclusive with w; if these are used in
    combination, x unsets both e and w, while either e or w overrides x.

You can see that I made the statement about multiple applications of
what I term a column modifier more general, because it is.  Much of the
x/e/w language, I retained.[1]

I'd welcome your further thoughts on how the tbl(1) man page might be
improved.

Regards,
Branden

[1] Ralph has yet to characterize even a single one of the 4,000+
    changes I've made to groff and its documentation as an improvement.
    He also tends to fall quiet when rebutted with a point that seems
    difficult to contradict.[2]  This is a familiar debate tactic in
    synchronous forums like mailing lists.  One never actually concedes
    a point; rather, one lets the entire topic time out.  If challenged,
    one can always claim that one was busy/missed your message/was in
    hospital, and imply or state that your counterparty is impatient or
    rude.  (They always have better things to do than argue with you,
    like launch a fresh drive-by derogatory comment on some new subject,
    for which their time budget is boundless.)  This sort of person does
    whatever avoids turning the subject back to the unrebutted/
    unconceded issue.  It is therefore difficult to tell, for instance,
    when Ralph is satisfied, though he is notably less reticent to
    acknowledge the merits of AT&T troff and neatroff, upon which he is
    comparatively plenteous.  Sucks to be GNU, eh?

[2] Since I can already hear the charge that this claim lacks
    foundation--oh, how the memory cheats--I will cite a few examples
    from this month.

    https://lists.gnu.org/archive/html/groff/2023-04/msg00280.html

    A.  Impliying a binary status in *roff mode names is not helpful
        when a mode is not of Boolean nature, or is not orthogonal with
        other *roff modes.

    B.  Applying a name even to the inverse of a Boolean-valued mode can
        be useful when it aids the user to mentally model what the
        inverse of that mode implies.  E.g., when we're not in "copy
        mode", we must not be "copying".  What does that mean?

    C.  Sustainable documentation, like sustainable code, is [or should
        be] written for the benefit of people other than the author at
        their moment of maximum familiarity with the work.

    https://lists.gnu.org/archive/html/groff/2023-04/msg00098.html

    D.  The variability of the font files used with groff means that
        pixel-precise validation of generated output is not, in general,
        an achievable goal.

signature.asc
Description: PGP signature