Description
The following can be verified on the online demo, as well as recent pandoc release.
Consider the following table:
<table>
<tr>
<td rowspan=2><p>a</p><p>rowspan2</p></td>
<td colspan=2><p>b</p><p>colspan2</p></td>
<td rowspan=2><p>c</p><p>rowspan2</p></td>
</tr>
<tr>
<td>d</td>
<td>e</td>
</tr>
</table>
A browser would render it to something that looks like this:
+----------+----------+----------+
| a | b | c |
| | | |
| rowspan2 | colspan2 | rowspan2 |
| +-----+----+ |
| | d | e | |
+----------+-----+----+----------+
A markdown output by pandoc (through its SimpleTable) will output this legacy style grid:
+----------+----------+----------+-----------+
| a | b | | c |
| | | | |
| rowspan2 | colspan2 | | rowspan2 |
+----------+----------+----------+-----------+
| | d | | e |
+----------+----------+----------+-----------+
(custom writer and to_simple_table in Lua filters will get the same result)
However, I expected this instead:
+----------+----------+----------+-----------+
| a | b | | c |
| | | | |
| rowspan2 | colspan2 | | rowspan2 |
+----------+----------+----------+-----------+
| | d | e | |
+----------+----------+----------+-----------+
So I don't know why the "e" was moved to an adjacent cell.
That is, I expected merged cells of rowspan = rs and colspan = cs to be rendered as rs * cs cells of 1x1 dimension, where the content would be put in the top-left cell, with the other cells empty and put on the grid "naturally", and non merged cells to be where they are expected to be.
If this is not a bug, is there some rule to predict the position of cells in Legacy mode (for a non-Haskell coder) ?
I can compensate with some methods to get the kind of grid I expect, but getting it from pandoc would simplify things.
Additional reference: The above example comes from a simplified version of this table with which I was doing some tests (custom writer that outputs complex grid tables). If you force pandoc to do a grid representation, you'll get the same problem I described above.