Bug 162537 - A specific docx file is unreadable
Summary: A specific docx file is unreadable
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.6.1.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected
Depends on:
Blocks: Writer-Tables
  Show dependency treegraph
 
Reported: 2024-08-21 11:17 UTC by boris_petrov
Modified: 2025-09-09 18:17 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Broken template (242.89 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2024-08-21 11:17 UTC, boris_petrov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description boris_petrov 2024-08-21 11:17:51 UTC
Created attachment 195926 [details]
Broken template

Please check the attached document. It's "broken" in the sense that some things are missing - for example the "a", "b" and "c" in one of the rows. That's a stripped-down version of a document I have which is missing most of the information in it. But that should be enough for you to debug it.

Opening it in MS Office shows it correctly.

The issue seems to disappear if anything in the template is changed - for example if the image is removed, the bold `.` is removed, the rows in the table are not 11 but 10 or less, etc.
Comment 1 4layq596ovwv 2024-08-21 11:24:32 UTC
I have tested this as well on my machine on  LibreOffice 24.2.5.2 bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 and can confirm that the output is not correct.

The issue is also linked to this github issue : https://github.com/open-xml-templating/docxtemplater/issues/758
Comment 2 Regina Henschel 2024-08-21 13:13:39 UTC
Second table is wrong. Position of first table or image is wrong. Tested with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: e9899b5c29bc9390d9b47b40faab6d27797ac4d3
CPU threads: 32; OS: Windows 11 X86_64 (10.0 build 22631); UI render: default; VCL: win
Locale: de-DE (de_DE); UI: en-US
Calc: threaded
Comment 3 BogdanB 2025-09-09 17:09:29 UTC
Tested also in
Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 67ea1fc544a0651e8da78531cfa3525f72c434ef
CPU threads: 16; OS: Linux 6.14; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 4 Timur 2025-09-09 18:17:54 UTC
Started in 24.2 and 7.6.

commit 5b3fcbf23773ea8d039185dec2b9704981833473	[log]
author	Michael Stahl <michael.stahl@allotropia.de>	Wed Aug 23 15:50:59 2023 

tdf#156724 sw: layout: fix tables not splitting due to footnotes differently

Revert commit 610c6f02b11b4b4c555a78b0feb2a1eb35159e39 and
and 61a78a523a6131ff98b5d846368e5626fe58d99c instead do the
opposite: never calc content frames in FormatLayout().

There were a few cases where documents looked worse with the fix, such
as the somewhat pathological tdf120139-1.odt and tdf124474-1.odt, but
typically these went from a bad layout to a worse layout, e.g.
--convert-to pdf tdf120139-1.odt went from 11 minutes to 33 minutes
(dbgutil) with twice as many more half-empty pages.

Worse is that the previous fix appears to prevent tdf#128437 from
working.


Usually this is regression but reading the commit, it is hard to reconcile all so I do not tag so.