https://bugs.documentfoundation.org/show_bug.cgi?id=172650
Bug ID: 172650
Summary: Non-deterministic line wrapping when exporting XLSX to
PDF (headless `--convert-to pdf`)
Product: LibreOffice
Version: 24.2.5.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
Description:
Converting the same .xlsx to PDF with headless soffice (--convert-to pdf)
produces different output on different runs, with no change to the input file.
A horizontally-merged cell whose value contains a hard line break (U+000A) is
usually rendered as two lines, but on a minority of runs it collapses onto a
single line. Input file, command, and environment are identical between runs.
In ~5 of 30 runs the cell was rendered on one line instead of two. Rendered
pixels differ (not only the text layer). Originally found in a server-side
pipeline that regenerates the same ledger PDF repeatedly; end users reported
"the same data produces a different-looking PDF every time".
Steps to Reproduce:
1. Open/convert the attached Book1.xlsx. It has a cell on sheet "ページ2" (merged
O3:R3) whose value is "123数値\nテストスウチ " (text + hard line break + text). The
cell style has BOTH wrapText="1" and shrinkToFit="1" set, and the row has a
fixed height (ht="20", customHeight="1", i.e. one line tall).
2. Convert to PDF in headless mode 20-30 times, using a FRESH user profile each
time:
for i in $(seq 1 30); do
rm -rf "/tmp/lo_$i"
soffice --headless -env:UserInstallation="file:///tmp/lo_$i" --convert-to
pdf --outdir "/tmp/out_$i" Book1.xlsx
done
3. Compare the results:
for i in $(seq 1 30); do pdftotext "/tmp/out_$i/Book1.pdf" - | md5sum; done
| sort | uniq -c
Actual Results:
The 30 PDFs are NOT identical. In this run, 25/30 rendered the cell as two
lines ("123数値" / "テストスウチ"), and 5/30 collapsed it onto a single line
("123数値テストスウチ"). The extracted-text MD5 fell into 4 distinct groups (25 / 2 / 2
/ 1). The rendered pixels also differ (verified with `magick compare`). See
attached images: correct_2lines_run18.png (two lines) vs buggy_1line_run19.png
(one line) — same input file, different runs.
Expected Results:
Converting the same file with the same command in the same environment should
be deterministic: every run should produce an identical PDF, and the hard line
break should always be honored (two lines) on every run.
Reproducible: Sometimes
User Profile Reset: Yes
Additional Info:
Version: 24.2.5.2 (AARCH64) / LibreOffice Community
Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59
OS: macOS 26.5 (arm64)
Also reproduced on LibreOffice 7.6 (Linux, headless) in production (AWS
Lambda).
https://github.com/t4traw/libreoffice_sample
Note: in a minimal single-cell document the same cell renders
deterministically; the non-determinism only appears in a more complex document
(multiple sheets, many merged cells), which suggests a timing/state-dependent
path in the layout / row-height computation rather than a pure data issue.
--
You are receiving this mail because:
You are the assignee for the bug.
