Bug 169944 - DOCX: Table cell in LO has border spacing of 0.08in, but in MS Word it is 0 (comment 7)
Summary: DOCX: Table cell in LO has border spacing of 0.08in, but in MS Word it is 0 (...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Floatingtable
  Show dependency treegraph
 
Reported: 2025-12-11 18:47 UTC by Denis
Modified: 2026-03-21 23:45 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Buged file (11.66 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-12-11 18:47 UTC, Denis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Denis 2025-12-11 18:47:04 UTC
Description:
The error in displaying the table in the document should be displayed on 1 page, the libre is displayed on 2

Steps to Reproduce:
1.Open
2.
3.

Actual Results:
displaying the table in the document should be displayed on 1 page, the libre is displayed on 2

Expected Results:
the table in the document should be displayed on 1 page


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 25.2.2.2 (X86_64) / LibreOffice Community
Build ID: 520(Build:2)
CPU threads: 12; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+xcb)
Locale: ru-RU (ru_RU.UTF-8); UI: ru-RU
Calc: threaded
Comment 1 Denis 2025-12-11 18:47:46 UTC
Created attachment 204586 [details]
Buged file
Comment 2 Roman Kuznetsov 2025-12-11 19:00:48 UTC
Confirm in

Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 620(Build:0)
CPU threads: 16; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win
Locale: ru-RU (ru_RU); UI: en-US
Calc: CL threaded
Comment 3 Telesto 2025-12-11 21:13:18 UTC
Two pages, but content fits at least on a single page with (so empty page two)
Version: 7.4.0.3 / LibreOffice Community
Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a
CPU threads: 8; OS: Mac OS X 14.7.4; UI render: Skia/Raster; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

last table row on second page with
Version: 26.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: d20f7e9b86f2efa258db3e8456dd24d94190e0c5
CPU threads: 8; OS: macOS 14.7.4; UI render: Skia/Raster; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

Adding bibisect request
Comment 4 raal 2025-12-12 20:29:56 UTC
This seems to have begun at the below commit in bibisect repository/OS linux-64-7.6.
Adding Cc: to Miklos Vajna ; Could you possibly take a look at this one?
Thanks
 fcf57c8efc126fb5a1cabefd2a3e8d33c57d5860 is the first bad commit
commit fcf57c8efc126fb5a1cabefd2a3e8d33c57d5860
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Sat Oct 28 11:07:42 2023 +0200

    source ce3308a926f036b87515b8cd97d2b197063dc77a

150252: tdf#61594 sw floattable: import floating tables as split flys by default | https://gerrit.libreoffice.org/c/core/+/150252
Comment 5 Timur 2025-12-14 19:41:43 UTC
That is enabling commit, we can go back and search real commit using SW_FORCE_FLY_SPLIT=1.

commit d477fa8ac1b0d3ee81427217bbb5950278ab16db	[log]
author	Miklos Vajna <vmiklos@collabora.com>	Fri Mar 17 14:00:17 2023
sw floattable: unconditionally map <w:tblpPr> to SwFormatFlySplit
Comment 6 Miklos Vajna 2025-12-15 08:30:42 UTC Comment hidden (obsolete)
Comment 7 Justin L 2026-03-21 23:45:40 UTC
repro 26.8+ with 1 (2).docx     (with lots of caveats)

First of all, note that the page is REALLY FULL in MS Word. So to get it to fit on one page in LO means EVERYTHING needs to be perfect.

But this is not really related to Miklos at all. The only reason it works in 7.5 is because the content starts way too high. Now with Miklos' commit, the content starts at the correct spot on the page. So his work is actually an improvement. [removing regression/blame]

One big problem is that the first row of the table takes up 3 lines in LO, but only two lines in MS Word. So right off the bat we have already lost one line of precious space. (already in 3.4.0). Before that the table was different, but it still had 5.4pt left and right border 'spacing to contents'. [Inherited from OOo 3.3]

But even with that manually removed, there are still some minor spacing differences that affect the height of various rows.

And even in LO 7.5 the document still opened with 2 pages - only that the tables themselves all fit on one page. The second page contained the final CR.

So this document has never been even close to correct. Let's change the bug report to deal with the most visible aspect - the 3-line height of the first row of the table due to the border spacing.

Steps to reproduce:
1.) open 1 (2).docx in LO.

Notice that the first cell ('Номер доверенности') takes up three lines of space, and has 0.19cm border spacing to contents for Left and Right.