Every table this backend writes is missing its w:tblGrid. POI's XWPFDocument.createTable
does not emit one and DocxSemanticBackend does not add it, so the element CT_Tbl requires
is absent from every .docx the backend has ever produced.
Word is tolerant enough to open the file and infer a grid, which is why nothing has surfaced
it, but the document is not valid against the schema and a stricter consumer is entitled to
reject it. It also leaves the column widths to the reader: DocumentTableColumn specs are
resolved by layout and never reach the file, so a table exports with Word's guess rather than
the widths the author asked for.
Pre-existing and backend-wide — not introduced by #523/#524/#525. Found while reviewing the
table-grid work.
Fixing it means emitting w:tblGrid with one w:gridCol per grid column, which
TableGrid.columnCount already resolves; the widths would come from the column specs, in
twips.
Note this will move the output of every committed .docx preview, so it lands together with a
re-render.
Every table this backend writes is missing its
w:tblGrid. POI'sXWPFDocument.createTabledoes not emit one and
DocxSemanticBackenddoes not add it, so the elementCT_Tblrequiresis absent from every
.docxthe backend has ever produced.Word is tolerant enough to open the file and infer a grid, which is why nothing has surfaced
it, but the document is not valid against the schema and a stricter consumer is entitled to
reject it. It also leaves the column widths to the reader:
DocumentTableColumnspecs areresolved by layout and never reach the file, so a table exports with Word's guess rather than
the widths the author asked for.
Pre-existing and backend-wide — not introduced by #523/#524/#525. Found while reviewing the
table-grid work.
Fixing it means emitting
w:tblGridwith onew:gridColper grid column, whichTableGrid.columnCountalready resolves; the widths would come from the column specs, intwips.
Note this will move the output of every committed
.docxpreview, so it lands together with are-render.