Word Document table conversion issue

[He-Huang]

This library is great. It would be even more useful if the table conversion is accurate with merged cells.

With the table inside this docx file

I got the parsing results as below:

| 1 | 2 | 3 | 4 | 5 | 6 | |
| --- | --- | --- | --- | --- | --- | --- |
| A | b | c | d | e | f | value |
| I | J | K | L | M |
| P | Q | R | S | T |

After rendering in markdown, it's like

1	2	3	4	5	6
A	b	c	d	e	f	value
I	J	K	L	M
P	Q	R	S	T

[mick-net]

Markdown tables seem to lack complex table functionality. Maybe complex table's can be converted to html tables (since llm & markdown viewers can usually also work with this).

[brc-dd]

pandoc's output is bit better:

1	2	3	4	5	6
A	b	c	d	e	f	value
	I	J	K	L	M
	P	Q	R	S	T

mammoth's html output is also correct (except it doesn't detect headers row properly, but it's still usable, ref - mwilliamson/mammoth.js#126).

The issue seems to be this - matthewwithanm/python-markdownify#121

We can use the mentioned workaround. We already have pandas in deps. It will give output like this:

1	2	3	4	5	6	6.1
A	b	c	d	e	f	value
A	I	J	K	L	M	value
A	P	Q	R	S	T	value

[He-Huang]

Thanks @brc-dd! Pandoc works perfectly in my trail.
Hopefully it will be integrated inside the markitdown so that we can get an embedded html tables within the markdown output.

[Utopiah]

pandoc's output is bit better

Not to hijack this issue but can you please explain what's the difference in terms of quality and features (so excluding programming language, funding institution and community) between this tool and Pandoc? I discovered it recently and my first thought was indeed, what does it do better than what I already know and use, namely pandoc or soffice, and why are those not contributions to such existing FLOSS projects?

Edit: seems there is audio transcription, not sure what's the use case in this context though.

[LCorleone]

markdown is not suitable for complex table, maybe xml is a good choice.

[BFuhry]

In my case, I use the markdown result as source for a documentation build on mkdocs for material. By default, mkdocs for material is also not able to handle tables with merged cells, but the mkdocs-plugins extension makes this possible.

Unfortunately, the current result is not suitable, because it does not contain the correct number of | to represent the table.
As a result, I manually have to add | at a lot of places. The pandoc output mention by @brc-dd is better, because it - using the extension mentioned above - would only require to add @span to a few cells to enable such a complex table.

[iamckun]

It issues seems to not have been noticed yet. I wonder when I can use this correctly in a markitdown. Currently, large models often make misunderstandings due to incorrect merging of cells, which affects their correct interpretation of the actual intent.

[StaryMoon]

I implemented the HTML-table approach discussed above in #2224.

The change preserves DOCX tables containing rowspan or colspan as semantic HTML, so merged-cell relationships are no longer lost during the markdownify step. Simple DOCX tables still use the existing pipe-table Markdown output, and direct HTML conversion keeps its current default behavior.

The PR includes regression tests for row spans, column spans, simple tables, and conversion scope, plus an end-to-end check with a DOCX containing both horizontal and vertical merges.