Bug 135713 - FILEOPEN DOCX Long BTLR text in table not entirely visible if it overflows to next page
Summary: FILEOPEN DOCX Long BTLR text in table not entirely visible if it overflows to...
Status: VERIFIED DUPLICATE of bug 138600
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx
Depends on:
Blocks: DOCX-Tables
  Show dependency treegraph
 
Reported: 2020-08-13 13:06 UTC by NISZ LibreOffice Team
Modified: 2021-08-05 08:55 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot of the problem in Writer (133.01 KB, image/png)
2020-08-13 13:06 UTC, NISZ LibreOffice Team
Details
Comparison MSO 2010 and LibreOffice 7.1 master (68.78 KB, image/png)
2020-08-13 13:45 UTC, Xisco Faulí
Details
The minimized example file in Word and Writer 7.2master (196.78 KB, image/png)
2021-01-11 09:10 UTC, NISZ LibreOffice Team
Details
screenshot (77.54 KB, image/png)
2021-02-05 20:08 UTC, BogdanB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description NISZ LibreOffice Team 2020-08-13 13:06:28 UTC
Created attachment 164257 [details]
Screenshot of the problem in Writer

This is followup to bug #127118
The original example file has a long BTLR text in the first, merged column of the table.
After that fix the part of the text that falls to the second page is not visible.


Steps to reproduce:
    1. Open attachment attachment #154864 [details]

Actual results:
First column has no visible text on the second page: “mi quis pretium semper.” is missing (alhough it can be selected and copied)

Expected results:
All text is visible.

LibreOffice details:
Version: 7.1.0.0.alpha0+ (x86)
Build ID: <buildversion>
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL
(same with x64 build and “UI render: default;” too)
Comment 1 Xisco Faulí 2020-08-13 13:45:38 UTC
Created attachment 164258 [details]
Comparison MSO 2010 and LibreOffice 7.1 master
Comment 2 Xisco Faulí 2020-08-13 13:46:12 UTC
I can't reproduce it in

Version: 7.1.0.0.alpha0+
Build ID: df37937018fe8e87dad5dd97689632044ba56de3
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

at least, comparing it to MSO 2010, the result seems to be correct, isn't it ?
Comment 3 NISZ LibreOffice Team 2020-08-18 08:12:02 UTC
(In reply to Xisco Faulí from comment #2)
> I can't reproduce it in
> 
> Version: 7.1.0.0.alpha0+
> Build ID: df37937018fe8e87dad5dd97689632044ba56de3
> CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3
> Locale: en-US (en_US.UTF-8); UI: en-US
> Calc: threaded
> 
> at least, comparing it to MSO 2010, the result seems to be correct, isn't it
> ?

For some reason in your Writer the BTLR column is way wider than in Word and the text fits in two lines on the first page. 
I can do that by increasing the column width and it starts to appear but this is about opening time. 
So: why is that first column wider for you?
Comment 4 Xisco Faulí 2020-12-07 18:07:20 UTC
Hello NISZ Team,
please attach a comparison LibreOffice Vs MSO screenshot
Comment 5 NISZ LibreOffice Team 2021-01-11 09:10:09 UTC
Created attachment 168813 [details]
The minimized example file in Word and Writer 7.2master

Still the same in:

Version: 7.2.0.0.alpha0+ (x64)
Build ID: 8e691505d4675b878b30bd00cd2e4fb4f794f0ef
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL

Also the same with Skia enabled.
Comment 6 BogdanB 2021-02-05 20:08:29 UTC
Created attachment 169516 [details]
screenshot

This is how it looks on
Version: 7.1.0.3 / LibreOffice Community
Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 7 BogdanB 2021-02-05 20:09:50 UTC
And the same screenshot in
Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: 40b56cd8da8c38582dc4660b486993d1b4711535
CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: ro-RO (ro_RO.UTF-8); UI: en-US
Calc: threaded
Comment 8 NISZ LibreOffice Team 2021-07-21 08:47:53 UTC
This seems to have been fixed with:

https://git.libreoffice.org/core/+/20f12960ae546ab90b1e216d5ed3f0dc576f1b48

author	Miklos Vajna <vmiklos@collabora.com>	Mon Dec 14 21:05:02 2020 +0100
committer	Miklos Vajna <vmiklos@collabora.com>	Wed Dec 16 09:08:55 2020 +0100

tdf#138600 sw: fix too small print area for btlr text in nested table

Thanks Miklos for fixing this one!

*** This bug has been marked as a duplicate of bug 138600 ***
Comment 9 NISZ LibreOffice Team 2021-08-05 08:55:49 UTC
Verified in: 

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: ad1b12686da88bea57582df10fa85268ada209b8
CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: default; VCL: win
Locale: hu-HU (hu_HU); UI: hu-HU
Calc: threaded