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.
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
"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]>:
> 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
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
hi Larry,
i thing chris has a more basic problem
the last time i need .TS H i needed also the -ms macroset.
tbl alone did not help (yes, it was an older version)
i used: groff -t -ms -Tps my.tbl
(shorten version of cause in real it is:
cat <> According to page 6 of the document "tbl - A program
> 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
> > 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
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
> > 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]>:
> > > 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
This is for Ted Harding and others who have felt they weren't being
sufficiently informed about the changes I've been making. Comments
and suggestions welcomed.
1. EQN
The new MathML back end to eqn continues to just work.
I thought I had come up with a way to implement mark/lineup, but ther
On 07-Feb-07 Eric S. Raymond wrote:
> This is for Ted Harding and others who have felt they weren't being
> sufficiently informed about the changes I've been making. Comments
> and suggestions welcomed.
Thanks! Comment regarding EQN following:
> 1. EQN
>
> The new MathML back end to eqn contin
Ted Harding <[EMAIL PROTECTED]>:
> As you can see,
> the lineup does its job, despite the intervening text. (And
> it carries over past page-breaks too).
>
> I don't see how this is compatible with your description
> of troff "treating multiple adjacent .EQ/.EN s
Mike, I realized this morning that the existence of a MathML backend
for eqn means you now need to write a stylesheet that transforms presentation
MathML to eqn and add it to the standard set.
Otherwise, we'll be in a repeat of the unhappy situation with TBL. Man pages
will actually be preferred
On 07-Feb-07 Eric S. Raymond wrote:
> Ted Harding <[EMAIL PROTECTED]>:
>> As you can see,
>> the lineup does its job, despite the intervening text. (And
>> it carries over past page-breaks too).
>>
>> I don't see how this is compatible with your description
>> of
Ted Harding <[EMAIL PROTECTED]>:
> I.e., can one set a "global variable2 in MathML? Where, in this
> case, it would have the value of the offset at the "mark" point,
> and be called on for setting offsets at subsequent "lineups"?
Alas, the answer is "no".
The MathML designers chose a model in whi
Hi Eric,
> @2007-02-07 16:17 -0500:
> Mike, I realized this morning that the existence of a MathML backend
> for eqn means you now need to write a stylesheet that transforms presentation
> MathML to eqn and add it to the standard set.
Actually, it's good to have this extra incentive to write such
On 07-Feb-07 Eric S. Raymond wrote:
> Ted Harding <[EMAIL PROTECTED]>:
>> I.e., can one set a "global variable2 in MathML? Where, in this
>> case, it would have the value of the offset at the "mark" point,
>> and be called on for setting offsets at subsequent "lineups"?
>
> Alas, the answer is "no
Michael(tm) Smith <[EMAIL PROTECTED]>:
> Yep. By the way, can you give some numbers on how many existing
> man pages in your Red Hat corpus are using eqn markup?
I just counted 173. Most are in a 3D graphics library attached to X,
mesa-libGLU.
> > The hardest part will probably be implementing t
I'm going to take a look at fixing gtbl to handle T{ T} better.
Werner, do you have a gtbl test suite? If not, would you consider putting
some time into writing test loads and regressions?
I'd do it, but it's better practice to have the tests written by someone
other than the coder. Besides,
21 matches
Mail list logo