Why does Word read out duplicate content when merging cells?

This paper uses synthetic samples to demonstrate the processing method. The code has been verified using examples in an isolated environment; this does not guarantee effectiveness for all real-world files or products. Before processing important files, please retain the original copies and verify them against the boundaries and acceptance criteria outlined in this document. Which problem does this paper address first merged cells appear repeatedly in layout grid access and cannot be deduplicated by text. This synthetic example constructs only horizontal merges; omitting grid columns requires a genuine, valid OOXML sample and cannot be simulated by arbitrarily adding attributes to rows. self-contained synthetic example dependencies are listed in the import section. The code constructs inputs in memory; runtime logs are provided separately and do not constitute a guarantee for all real-world files. from docx import Document from io import BytesIO doc = Document() table = doc.add_table(rows=2, cols=3) table.cell(0, 0).merge(table.cell(0, 1)).text = "Group A" table.cell(0, 2).text = "Total" for cell, text in zip(table.rows[1].cells, ["same", "same", "20"]): cell.text = text out = BytesIO() doc.save(out) out.seek(0) restored = Document(out).tables[0] rows = [[cell.text for cell in row.cells] for row in restored.rows] assert rows[0] == ["Group A", "Group A", "Total"] assert rows[1] == ["same", "same", "20"] assert len(rows[1]) == 3 assert restored.rows[0].cells[0]._tc is restored.rows[0].cells[1]._tc assert restored.rows[1].cells[0]._tc is not restored.rows[1].cells[1]._tc Why does the read-out table always have “extra” data? When you use python-docx When iterating through a Word table that contains merged cells, the most common issue is not failing to read any content, but rather reading too much. For example, a header row that visually spans two columns—“Project Name”—will be returned twice in the code loop, once for each of the two grid positions it covers. If you simply concatenate or store this text directly, downstream data-cleaning processes will mistakenly treat the same value as two separate records. This is not a bug in the library, but rather a mismatch between Word’s underlying table model and human visual perception. At its core, a Word table is an invisible “layout grid,” with each cell required to align to this grid. Merging cells merely creates a visual object that spans multiple grid coordinates; however, in the XML structure, these coordinates must still be fully occupied to maintain matrix integrity. Therefore, row.cells defaults to returning the “grid view” rather than the “visual view.” To properly handle tables, this setting must first be accepted: the program reads grid indices, not rendered tiles. Error Input and Boundary Handling : If used directly [c.text for c in row.cells] without processing grid_cols_before and grid_cols_after , the first line will become ["标题A", "标题B"] , causing the column indices of all subsequent rows to shift left by one position. This misalignment does not trigger an error, but it completely corrupts the semantics of the entire table. For nested tables (tables embedded within cells), this example handles only the top-level grid; if recursive parsing is required, the same grid-alignment logic must be applied separately to each cell, and it cannot be assumed that the row and column counts of the outer layer apply to the inner layers. Python parsing implementation based on the layout grid The core of this code lies in acknowledging that “duplication” is valid. In the second line, “merged value” appears twice because it indeed occupies both (1,0) and (1,1) positions within the layout grid. Critical Warning : If your business logic requires deduplication, you must perform it after parsing, based on the memory references of cell objects (such as id(cell) ) should be used for judgment; under no circumstances should deduplication rely solely on text values—because two separate, unmerged cells may perfectly well have identical text, and deduplicating based on text alone would result in data loss. Acceptance Criteria and Manual Review Boundary code can resolve grid alignment issues, but it cannot automatically determine the semantic completeness of tables. The following table summarizes the acceptance criteria for automated parsing and the scenarios that must be handed over to human review. Please note that “code demonstration passed” only indicates that the grid indices are aligned correctly; it does not imply that the extracted content is operationally usable. Clearly defined inapplicable scenarios: This method applies only to Word’s native table model. For tables converted from PDFs or generated by pasting HTML, their XML structure may be incomplete. grid_cols_before and other key attributes; at this point, the automated parsing results cannot be trusted and should be directly flagged for manual verification. Furthermore, if the table employs complex text wrapping or absolute positioning, the layout grid itself becomes invalid, and the matrix generated by the code will significantly deviate from the visual presentation. References and Next Steps python-docx official documentation: Working with Tables（https://python-docx.readthedocs.io/en/latest/user/tables.html） Open XML SDK Documentation: Table Grid Specification (Microsoft Official Technical Document) The decision on handling the specific exception observation What should be done should not infer repeats the same cell as is understood as grid mapping does not duplicate the translation of merged entity Two text segments are identical retains two identity slots do not deduplicate by text omitted grid column also provides a valid OOXML sample does not forge row attribute test uses this checklist for document translation Word translations often blur the line between content issues and formatting problems. Leave checks for styles, headers, tables, and other elements to the delivery checklist, so reviewers know exactly where to look. OmniDoc (Product Entry) provides an entry point for translating multi-format documents, and the official website highlights its OCR, terminology database, and bilingual alignment features. For teams that wish to start processing directly from files, this is a path worth evaluating with real-world samples. Please use de-identified files that you are authorized to upload, and verify the results against the checklist provided in this document; we do not claim that OmniDoc utilizes the open-source libraries or internal algorithms referenced herein, nor do we substitute examples for product performance testing. - 1 -