Table formatting
opoudjis opened this issue · comments
Child of #59
Asciidoctor supports the following:
- frame could be all, topbot, sides or none. topbot and sides are not creating the intended effect and is just same as all.
- grid could be all, rows, cols or none. However it's not really having an effect.
I had only implemented grid. Will need to check.
I found that this configuration works:
[cols="2*^", frame="sides", grid="cols"]
|===
|ttcol #1 |ttcol #2
|c #1 |c #2
|c #3 |c #4
|c #5 |c #6
|===
Asciidoctor differentiates between frame attributes, for borders between cells, and grid attributes, for borders around tables.
RFC XML v3 ignores border style completely.
RFC XML v2 only has a single style attribute, that does the following:
2.39.3. "style" Attribute
Selects which borders should be drawn, where
o "all" means borders around all table cells,
o "full" is like "all", except no horizontal lines between table
rows (except below the column titles),
o "headers" adds just a separator between column titles and
rows, and
o "none" means no borders at all.
The Asciidoc frame attribute references external borders; the RFCXML v2 style attribute only references internal borders. So the Asciidoc frame attribute is irrelevant to RFCXML.
The grid attribute is mapped as follows:
grid = all
=>style = all
grid = rows
=> [not supported]grid = cols
=>style = full
grid = none
=>style = none
The style=header
value is noted as not supported.
[cols="2*^", frame="sides", grid="cols"]
and [cols="2*^",grid="cols"]
have identical output.
... What should I be doing diffferently?
An asciidoctor table can be made to show a "header" using the header
option:
[cols=2*, options="header"]
|===
...
Could this be the way we also cover style=header
in v2? This seems to be the issue with the "davies" diff right now.
I realized that the real problem is that many tables are actually rendered by the author as manual ASCII-art through artwork
, instead of using XML RFC's table feature. I was hoping that we could support "AsciiDoc table to artwork", but that might be too much work for us...
I think this has been dealt with to the extent it is realistic to...
Agree. Thanks!