groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] tbl footnotes and graph position


From: Tadziu Hoffmann
Subject: Re: [Groff] tbl footnotes and graph position
Date: Fri, 2 Dec 2011 23:41:43 +0100
User-agent: Mutt/1.5.21 (2010-09-15)


> I was so excited about the row height that I stopped looking
> at the bottom of the page.

Yeah, I didn't notice the missing footnotes either.


> Let me see if I understand what's going on here.
> 1.   TS, tbl starts
> 2.   tbl sees T{ ... T} and invokes troff
[snip]
> 6.   TE, tbl ends
> 7.   troff runs with -ms

That's not quite the way it works.  Troff runs only once.
Tbl acts as a preprocessor for troff, and modifies your input
between .TS and .TE before passing it onto troff.  (See also
the pipeline diagram in the "soelim" manpage.)  You can see
what tbl does by looking at the output of "tbl myinputfile".

Of course, the preprocessor method of operation implies some
complications.  Tbl actually has no idea how big individual
table entries are, and cannot make decisions based on this.
What it does instead is generate code that, when later run by
troff, will make the decisions (since troff is the program that
knows which fonts are being used and what their metrics are).

The code that tbl generates for text blocks looks something
like this: [step 1]

  .di unique-diversion-name
  .in 0
  .ll based-on-desired-column-width
  your text block content here
  .br
  .di

Then follows code which reads the "dn" and "dl" registers to
determine width and height of the diversion and compare them
to the results for other table cells in that row and column,
in order to be able to correctly align the table entries.
Later on, to write the cell contents into the table, the
following code is generated: [step 2]

  .nf
  .in computed-horizontal-position-of-left-cell-edge
  .unique-diversion-name

so whatever we ignored in step 1 is gone forever, since the
table cell diversion contains only what we decided to keep.

However, while initially filling the table cell diversion
in step 1, the footnote macro may redivert content away from
the table cell diversion into a "global" footnote diversion,
so the footnotes will not take up space in the table cell but
are instead collected separately, to be output when the text
reaches the bottom margin. This is the way the modified macro
is supposed to work.  (Caveat: I'm not sure whether the space
needed at the bottom of the page for footnotes is already
allocated correctly with this simple modification. But in
principle it is possible for the macro package to handle
footnotes in tables correctly.)

Now, while diversions are normally used to collect text
which has already been formatted (and in which all macros
and requests have therefore been "resolved"), it is possible
(using "\!") to embed macro calls in the diversion that
are executed when the diversion is reread.  (Kind of like
"hiding" backslashes by using "\\" while defining a macro,
so they only get recognized when the macro is later expanded.)
This is the way the second solution works.  But like you say,
it could be a bad hack because the page layout macros might
not be able to properly allocate space for the footnotes,
since they have no idea you will be needing additional space
until outputting the table has already begun.  (Still, a
"TS"/"TE" pair could first divert the entire table to measure
its height, in order to decide whether it will still fit on
the current page. During this diversion it would notice the
footnote requests, and could take appropriate action.)


> We could modify tbl to look for footnotes and transparently
> escape them.  Does that sound the like the right answer to
> you?

No, because footnote requests can look different depending on
which macro package you use, and we want tbl to be "agnostic".
This is a problem the macro package has to deal with.
(Which is possible; see my comments above.)





reply via email to

[Prev in Thread] Current Thread [Next in Thread]