Ted Harding <[EMAIL PROTECTED]>:
> "A key letter may be followed by the letter "X" to indicate an
> expanded column. If the modifier is used, the width of the
> corresponding column will be increased to use the remainder of the
> line length after the widths of the other columns have been
On 08-Feb-07 Michael(tm) Smith wrote:
> Tadziu Hoffmann <[EMAIL PROTECTED]>, 2007-02-08 12:19 +0100:
>> Nevertheless, does anybody here remember the discussion about
>> AT&T-tbl's "expand column" feature on this list some months
>> back?
>
> I don't remember reading that one. Is it something that
Tadziu Hoffmann <[EMAIL PROTECTED]>:
> I'm not familiar with DocBook, but doesn't it have something
> analogous to HTML's "definition list"?
Yes, a variablelist.
> It occurs to me
> that some of the "tables" you're discussing might be better
> served with such a
Tadziu Hoffmann <[EMAIL PROTECTED]>, 2007-02-08 12:19 +0100:
> I'm not familiar with DocBook, but doesn't it have something
> analogous to HTML's "definition list"?
It does -- DocBook has both a general-purpose element for marking
up associative lists -- which is called variablelist -- and a
spec
I'm not familiar with DocBook, but doesn't it have something
analogous to HTML's "definition list"? It occurs to me
that some of the "tables" you're discussing might be better
served with such a definition list (as is actually currently
the case).
Not every two-column table is a definition list,
Werner LEMBERG <[EMAIL PROTECTED]>:
> I doubt whether this is an acceptable solution.
Hmm. You're right.
> Indeed. The best so far is Gunnar's solution to emulate your
> suggested percent keyletter extension.
I think I just came up with something better, a way to compute the
column widths tha
> The worst case, if a viewer didn't implement the percent extension,
> is that we'd get lumpy tables as we do now.
No. The worst case is a viewer which uses an older groff version
without support for the percent extension -- the table completely
disappears:
.TH
xxx
.TS
y y.
foo bar
Werner LEMBERG <[EMAIL PROTECTED]>:
> > > Well, then I'd really like to have some general solution
> > > (workaround) that would cause the cell widths in tables with any
> > > arbitary number of columns to set to something more reasonable
> > > than what tbl(1) currently does.
> >
> > That change n
> > In this particular case (this is, simple tables which can be
> > sufficiently emulated with TP/TQ), I favor optical appearance over
> > logical structure.
>
> Shouldn't we be looking for a way to fix TBL, rather than kludging
> around the problem?
TP/TQ for the example I've given is *fully* s
Werner LEMBERG <[EMAIL PROTECTED]>:
> T{ T} as implemented currently just sucks.
Agreed.
> In this particular case (this is, simple tables which can be
> sufficiently emulated with TP/TQ), I favor optical appearance over
> logical structure.
And I still fundamentally disagree with that.
Shouldn
> > Well, then I'd really like to have some general solution
> > (workaround) that would cause the cell widths in tables with any
> > arbitary number of columns to set to something more reasonable
> > than what tbl(1) currently does.
>
> That change needs to be made in tbl itself. Which is, I thin
> More generally, I disagree with Werner's position that TP/TQ is
> preferable to tables with T{ T} in them.
T{ T} as implemented currently just sucks. Please have a look at this
http://lists.gnu.org/archive/html/groff/2006-09/msg00022.html
for some nasty details.
> I'm going to change grof
On 07-Feb-07 Michael(tm) Smith wrote:
> [...]
> Well, then I'd really like to have some general solution
> (workaround) that would cause the cell widths in tables with any
> arbitary number of columns to set to something more reasonable
> than what tbl(1) currently does.
>
> I don't know actually
Michael(tm) Smith <[EMAIL PROTECTED]>:
> What if I just have the stylesheet embed the macro definition in
> the output of each page?
That would work.
> Well, then I'd really like to have some general solution
> (workaround) that would cause the cell widths in tables with any
> arbitary number of
"Eric S. Raymond" <[EMAIL PROTECTED]>, 2007-02-07 11:43 -0500:
> I wrote the documentation recently :-). From groff_man in CVS:
>
>.TQThe TQ macro sets up header continuation for a .TP macro. With
> it, you can stack up any number of labels (such as in a glos‐
>
Michael(tm) Smith <[EMAIL PROTECTED]>:
> But is there a backward compatible way to avoid T{...T} ?
Probably not in general. One special case worth capturing in that you
probably should not emit T{ T} when the cell content is a single token,
i.e. contains no whitespace.
> And looking in the Mac
Werner LEMBERG <[EMAIL PROTECTED]>, 2007-02-06 12:35 +0100:
> I still think that tables with T{...T} don't work well within man
> pages.
I see the specific problem in the example man page you attached,
and I've also seen the especially bad results produced when tables
have more than two columns.
"Eric S. Raymond" <[EMAIL PROTECTED]> wrote:
> .TS
> tab(@);
> lw10% lw90%.
One can do
.TS
lw(\n(.lu/10u) lw(\n(.lu*9u/10u).
This is possible because the content of w() is interpreted
by troff, not by tbl. Unfortunately it only works with GNU
tbl and Heirloom tbl because traditional tbl variant
Larry Kollar <[EMAIL PROTECTED]>:
> > This I don't understand. Ugly to read for whom? If w is chosen well
> > for the indent and point size, it will look as though the table was
> > filled to right margin by a smart algorithm.
>
> What might work for nroff might not work for troff -- and then
Eric S. Raymond wrote:
>>> The only problem with using w is that the number that needs to go to
>>> go next to it is brittle -- it may break if the table indent
>>> changes, or if the the point size changes, or if the margins change.
>>
>> I fully agree. It can make such man pages ugly to read.
Werner LEMBERG <[EMAIL PROTECTED]>:
> > > What's the problem with .TQ? Most of the data in groff_mm.man can
> > > be represented with this macro in a satisfying way, I believe.
> >
> > Since you say so, I assume it's possible. But I have not figured
> > out how yet.
>
> Have a looked at the atta
> > What's the problem with .TQ? Most of the data in groff_mm.man can
> > be represented with this macro in a satisfying way, I believe.
>
> Since you say so, I assume it's possible. But I have not figured
> out how yet.
Have a looked at the attached file.
> OK. But first, even if we don't fin
Werner LEMBERG <[EMAIL PROTECTED]>:
> What's the problem with .TQ? Most of the data in groff_mm.man can be
> represented with this macro in a satisfying way, I believe.
Since you say so, I assume it's possible. But I have not figured out
how yet.
> > Instead, let's steal a trick from the HTML
> Yes, I could go back, find tables with T} in them, and revert them
> to list markup and similar kluges. But that would just bring us
> trouble from another direction. Many of the weird constructs I
> replaced with tables (I'm thinking, for example, of the T2 macro in
> groff_mm.man) will compl
Werner LEMBERG <[EMAIL PROTECTED]>:
> looking again at groff_mm.man, I see that using T{...T} in tables
> gives ugly results. I think that this is a limitation of tbl which
> can't be worked around: For text blocks, you can't say `use the
> remaining line width' because they are processed earlier
Eric,
looking again at groff_mm.man, I see that using T{...T} in tables
gives ugly results. I think that this is a limitation of tbl which
can't be worked around: For text blocks, you can't say `use the
remaining line width' because they are processed earlier than the rest
of the table.
With o
26 matches
Mail list logo
