https://bugs.documentfoundation.org/show_bug.cgi?id=174340
Bug ID: 174340
Summary: DOCX import: text silently dropped when the document
body is a single multi-page table row (fixed layout, 2
cells); PDF export and Writer view both missing pages
Product: LibreOffice
Version: 25.8.5.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
Description:
A DOCX file whose entire body is wrapped in one 1-row x 2-cell fixed-layout
table loses most of its content when opened in Writer or converted to PDF: both
table cells render only their first few pages and the remaining text is
silently discarded, with no error or warning. Microsoft Word renders the same
file completely.
The file was produced by PDFKit.NET 12.2 (a PDF-to-DOCX converter), which emits
this whole-document-in-a-table shape, so this is a real-world input pattern
rather than a hand-crafted edge case. In the attached repro the row spans pages
1-3 and then both cells clip; content after the table renders normally.
Bisecting the file shows the trigger lives in the paragraph properties:
removing all w:pPr elements makes the document render completely, and removing
only w:spacing elements moves the clip point further down (more content fits
before clipping). Removing run properties, tabs, indents, justification,
switching tblLayout to autofit, or removing trPr makes no difference. A plain
synthesized multi-page table row with uniform paragraph properties does NOT
reproduce the bug, so the failure involves the specific property mix in this
document shape.
Steps to Reproduce:
1. Download the attached repro_anonymized.docx
2. Run: soffice --headless --convert-to pdf repro_anonymized.docx (or simply
open the file in writer)
3. Count the pages and compare the text against the source document
Actual Results:
The PDF has 3 pages. Both table cells stop rendering partway through; roughly
80% of the document's text (about 18,500 of 23,000 characters) is missing from
the output. Only the content after the table (a short signature block) appears
on the final page. No error, warning, or dialog is shown.
Expected Results:
The full document renders: 11 pages with all text present, matching what
Microsoft Word shows for the same file and what LibreOffice produces for the
attached control_anonymized.docx (identical content with only the table wrapper
removed), shown in expected_control.pdf.
Reproducible: Always
User Profile Reset: Yes
Additional Info:
Reproduced with fresh user profiles (each run used a new -env:UserInstallation
directory).
Builds verified:
- LibreOffice 26.2.1.2 (8399f6259d8c87f40e7255cdb3c9b958f5e08948), macOS arm64
- LibreOffice 25.8.5 and 25.8.7.3, Linux x86_64 (headless conversion service)
Document anatomy: single w:tbl wrapping the whole w:body; one row (cantSplit=0,
tblHeader=0); two cells; tblLayout fixed; tblW=10590 + tblInd=930 dxa exactly
fills the printable width of a 12240-dxa page with 360-dxa side margins; a
w:tblGridChange tracked-change remnant inside w:tblGrid; paragraph spacing
values include float artifacts such as w:line="278.00000000000006". No
w:ins/w:del text revisions and no w:vanish hidden text are present.
Attachments:
- repro_anonymized.docx: failing input, with all text replaced by
length-preserving lorem ipsum (no third-party data)
- control_anonymized.docx: same file with the table wrapper removed; renders
fully
- actual_repro.pdf: the 3-page broken output
- expected_control.pdf: the 11-page output of the control
--
You are receiving this mail because:
You are the assignee for the bug.
