Re: [Groff] tbl problems in man

2007-02-07 Thread Michael(tm) Smith
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.

Re: [Groff] tbl problems in man

2007-02-07 Thread Eric S. Raymond
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

Re: [Groff] tbl problems in man

2007-02-07 Thread Michael(tm) Smith
"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‐ >

Re: [Groff] tbl problems in man

2007-02-07 Thread Eric S. Raymond
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

Re: [Groff] tbl problems in man

2007-02-07 Thread Ted Harding
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

Re: [Groff] How to do Multipage tables?

2007-02-07 Thread walter harms
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

Re: [Groff] tbl problems in man

2007-02-07 Thread Werner LEMBERG
> 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

Re: [Groff] tbl problems in man

2007-02-07 Thread Werner LEMBERG
> > 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

Re: [Groff] tbl problems in man

2007-02-07 Thread Eric S. Raymond
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

Re: [Groff] tbl problems in man

2007-02-07 Thread Werner LEMBERG
> > 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

Re: [Groff] tbl problems in man

2007-02-07 Thread Eric S. Raymond
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

[Groff] A progress report

2007-02-07 Thread Eric S. Raymond
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

RE: [Groff] A progress report

2007-02-07 Thread Ted Harding
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

Re: [Groff] A progress report

2007-02-07 Thread Eric S. Raymond
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

[Groff] Eqn creates a challenge for Mike(tm) Smith

2007-02-07 Thread Eric S. Raymond
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

Re: [Groff] A progress report

2007-02-07 Thread Ted Harding
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

Re: [Groff] A progress report

2007-02-07 Thread Eric S. Raymond
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

Re: [Groff] Eqn creates a challenge for Mike(tm) Smith

2007-02-07 Thread Michael(tm) Smith
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

Re: [Groff] A progress report

2007-02-07 Thread Ted Harding
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

Re: [Groff] Eqn creates a challenge for Mike(tm) Smith

2007-02-07 Thread Eric S. Raymond
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

[Groff] Regression tests for tbl

2007-02-07 Thread Eric S. Raymond
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,