The pptx table reader (ooxml.js, typed/pptx/read.ts, readTableCell) returns a merged-away cell (hMerge="1" or vMerge="1") as an empty cell, { blocks: [] }, and puts colSpan/rowSpan on the anchor. The docx reader records gridSpan on the anchor and has no cell at all for the covered positions. So the same merged region has two shapes in the content model depending on the source format.
A downstream consumer met the consequence: its table builder was written for the docx convention (it pads colSpan - 1 placeholders itself), so feeding it pptx tables produced a phantom column per horizontal merge, a three-column table with one merged header came out as Region,Revenue,,. It fixed that by dropping the continuation cells in its reader.
I haven't checked whether documents.js's own consumers (the markdown, html and csv writers, the docx and odt table writers, anything that converts a table pivot from one format to another) double-count on a pptx-sourced table, and ContentTableCell in document-schema.js doesn't state whether covered positions are present. Two things to do: state the rule in the schema, and add a cross-format conformance test that reads a merged table from pptx, docx and odt and asserts the same grid, then writes it to each target and checks the column count. If they disagree, the reader that departs from the stated rule gets fixed.
The pptx table reader (
ooxml.js,typed/pptx/read.ts,readTableCell) returns a merged-away cell (hMerge="1"orvMerge="1") as an empty cell,{ blocks: [] }, and putscolSpan/rowSpanon the anchor. The docx reader recordsgridSpanon the anchor and has no cell at all for the covered positions. So the same merged region has two shapes in the content model depending on the source format.A downstream consumer met the consequence: its table builder was written for the docx convention (it pads
colSpan - 1placeholders itself), so feeding it pptx tables produced a phantom column per horizontal merge, a three-column table with one merged header came out asRegion,Revenue,,. It fixed that by dropping the continuation cells in its reader.I haven't checked whether documents.js's own consumers (the markdown, html and csv writers, the docx and odt table writers, anything that converts a table pivot from one format to another) double-count on a pptx-sourced table, and
ContentTableCellindocument-schema.jsdoesn't state whether covered positions are present. Two things to do: state the rule in the schema, and add a cross-format conformance test that reads a merged table from pptx, docx and odt and asserts the same grid, then writes it to each target and checks the column count. If they disagree, the reader that departs from the stated rule gets fixed.