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 than the rest > of the table. > > With other words, as soon as we have table entries which need T{...T} > -- and this happens quite often if the column contains more than a few > words -- we can't use a table at all to get a decently looking result. > > I see no solution to this problem. Specifying a width argument to > columns doesn't help either without a lot of troff register trickery > to compute the correct width in advance. > > Please revert to the previous formatting (I suggest using .TQ instead > of .TP to avoid empty lines). Doclifter might produce good results > for HTML, but the visual degradation if formatted for other devices is > not acceptable.
Ouch! 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 completely break manhtml and non-groff viewers. That's why I moved a lot of this stuff to tables to begin with. I agree that the T{ T} items on that page and some places elsewhere don't look very nice -- the column widths are too narrow and the entries look lumpy. I was actually concerned about this myself. But at least the tables will be readable everywhere. I submit that having the content be *completely* garbled by (for example) the GNOME help browser is a worse result than the degradation in visual quality you are seeing. I think we actually need to either solve this problem somehow or accept ugly-looking tables as the least-bad alternative. Fortunately, I think I way around the problem constraints. You say "Specifying a width argument to columns doesn't help either without a lot of troff register trickery to compute the correct width in advance." I think I understand that. But what if we don't have to specify the actual width? Instead, let's steal a trick from the HTML book and implement a column width syntax that specifies a fraction of total line width. After all, we will know \n[.ll] at the very start of table compilation. We can scale \n[.ll] by each specified column percentage during table format processing, before T{ T} processing occurs. Feed that to whatever machinery is constraining the T block widths and we're done. This seems like an elegant solution, unless I'm misconstruing something very basic about how TBL operates. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>