From: David G. <go...@py...> - 2005-04-04 19:28:44
|
[Nick Moffitt] >>> I'm eagerly awaiting 0.3.8 entering debian testing, what with its >>> listy tables, [David Goodger] >> If you're having so much trouble, just install Docutils from the >> current snapshot. [Nick Moffitt] > Well, given what you're saying below, I'm not sure that would > solve my problems. I meant only that a snapshot install would give you access to the list-table directive. Past that, you'll have to be more specific. > When I did my own hackish awk script, I used # the way they > use || in the example. Yes, "#" is a good alternative: +---+---+---+ | # T | F | +===+===+===+ | T # F | T | +---+---+---+ | F # T | F | +---+---+---+ >> Another idea is to add a "stub-columns" option to the "list-table" >> directive that will allow this somehow. One problem though -- the >> CALS table model doesn't support stubs. Some research is needed to >> see how to best handle stubs. > > I'm also not certain how the list-table stub column would be > visually apparent in the ReST source. Either as in the example above, or: .. list-table:: :header-rows: 1 :stub-columns: 1 * - XOR - T - F * - T - F - T * - F - T - F It's not the reST source I'm worried about, it's the doctree/XML. I haven't been able to find a standard for expressing stubs in the CALS/OASIS XML Exchange table model. My first idea would be to add an attribute to the colspec element, like "stub=1", producing the following psuedo-XML: <table> <tgroup cols="3"> <colspec colwidth="33" stub="1"> <colspec colwidth="33"> <colspec colwidth="33"> <thead> <row> <entry> <paragraph> XOR <entry> <paragraph> T <entry> <paragraph> F <tbody> <row> <entry> <paragraph> T <entry> <paragraph> F <entry> <paragraph> T <row> <entry> <paragraph> F <entry> <paragraph> T <entry> <paragraph> F The HTML writer could easily keep track of "stub" attributes and turn entries in stub columns into "th" elements. -- David Goodger <http://python.net/~goodger> |