Unexpected Legacy Table output

[kysko]

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.

[jgm]

I think this concerns toLegacyTable from T.P.Writers.Shared.

[jgm]

@despresc wrote this code and might be able to explain whether this behavior is intended.

[despresc]

It is not intended. What you expected should be what pandoc outputs. I've fixed the issue in the pull request I just created.

[kysko]

@despresc

As some kind of epilogue:

I've recently tested your fix against a few thousand (pseudo)randomly generated tables, ranging from about 6 000 to 13 000 cells each, with random row spans and col spans...

And there were no errors.

(where versions before the fix all failed the test)

Just see this as an independent "stress test" (with my own 'bean counter') that went beyond a few manual tests.

(of course, a multitude of positive tests doesn't give absolute certitude, but it's enough for me to go on from here... thank you again.)

[despresc]

It's no problem. Thanks for the testing as well.