Bug 135943 - FILESAVE DOCX: LayoutInCell Frame and and text split on import (comment 4) - opens differently wrong in MSO and LO
Summary: FILESAVE DOCX: LayoutInCell Frame and and text split on import (comment 4) - ...
Status: NEW
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: target:7.1.0
Keywords: bibisected, bisected, filter:docx
Depends on:
Blocks: DOCX-Textbox
  Show dependency treegraph
 
Reported: 2020-08-20 10:05 UTC by Telesto
Modified: 2022-07-13 14:24 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (9.82 KB, application/vnd.oasis.opendocument.text)
2020-08-20 10:06 UTC, Telesto
Details
Example compared in Word and LO 7.1 (122.94 KB, image/png)
2020-09-07 12:08 UTC, Timur
Details
135943_shapeWithText_LayoutInCell1_compat12.docx (9.21 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2020-09-08 14:05 UTC, Justin L
Details
Example and its DOCX in Word and Writer 7.2 (51.23 KB, image/png)
2020-12-04 08:58 UTC, NISZ LibreOffice Team
Details
attachment 165272 in Word and current Writer (189.08 KB, image/png)
2021-07-04 08:27 UTC, NISZ LibreOffice Team
Details
Example file in 7.5master (69.92 KB, image/jpeg)
2022-07-13 13:27 UTC, Attila Bakos (NISZ)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-08-20 10:05:57 UTC
Description:
Frame and and text split on export to DOCX (header) since 7.1

Steps to Reproduce:
1. Open the attached file
2. Save As DOCX
3. File reload

Actual Results:
Frame and content split

Expected Results:
Not so


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.beta1+ (x64)
Build ID: 2891e91a513520d68ea2b8c59c14335861a15253
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

not in
6.5
Comment 1 Telesto 2020-08-20 10:06:14 UTC
Created attachment 164488 [details]
Example file
Comment 2 Telesto 2020-08-20 10:06:49 UTC
They additional info is wrong

Found in 7.1 master, not in 
Version: 7.0.0.0.beta1+ (x64)
Build ID: 2891e91a513520d68ea2b8c59c14335861a15253
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 3 Xisco Faulí 2020-09-07 10:23:53 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=7cc353df4f0993228984fcda3efb2c9181dddafb

author	Justin Luth <justin.luth@collabora.com>	2020-08-13 12:02:39 +0300
committer	Justin Luth <justin_luth@sil.org>	2020-08-15 08:28:20 +0200
commit 7cc353df4f0993228984fcda3efb2c9181dddafb (patch)
tree 3396d00f9d9b4ac775417bf68f37d2666f38ff13
parent 4708fa80ac95f11bfbfd422bec52865a17b46fd9 (diff)
tdf#77794 writerfilter: compat15 - always bLayoutInCell

Bisected with: bibisect-linux64-7.1

Adding Cc: to Justin Luth
Comment 4 Justin L 2020-09-07 11:36:14 UTC
Round-trip as DOC - purple square is in cell A1 in LO and MS Word.
Round-trip as DOCX - purple squares is in cell A1 in LO and MS Word. This was fixed by the mentioned commit. Prior to that, the purple square was in C1.

The only problem is that the frame has not followed along. But if you view the position properties of the textbox and then click OK - then it moves. So this seems primarily like a layout issue - but perhaps it is a property-syncing issue that isn't resolved until the dialog resets it?

So I'm treating this as exposing an existing problem. Indeed, there are too many cases where the frame disconnects from the textbox or whatever.
Comment 5 Timur 2020-09-07 12:08:26 UTC
Created attachment 165228 [details]
Example compared in Word and LO 7.1
Comment 6 Justin L 2020-09-07 18:56:37 UTC
Mikios/László - you have recently done work on textbox sync with FollowTextFlow.

Is this just a layout issue?  It doesn't seem to change if I force the shape's RES_FOLLOW_FLOW_TEXT to be either true or false.

Interesting fact. If you remove the textbox from the purple frame, then add a new textbox, the frame jumps to cell C1 position. If you turn on position property "follow text flow", then only the frame moves to cell A1. If you again look at the properties and hit OK, this time the textbox moves.

The HoriOrient position seems to be reset at "random" moments in the layout code, and after that the textbox can sync to the frame's position.
Comment 7 Justin L 2020-09-08 14:05:20 UTC
Created attachment 165272 [details]
135943_shapeWithText_LayoutInCell1_compat12.docx

This file shows the un-synced position problem that needs to be fixed (which is not affected by my patch). The purple shape and the textbox should be in cell A1.
I assume that layout is restricting the requested offset to the maximum allowed by the cell, but that new position is not being synchronized back to the textbox.


proposed patch to avoid causing the problem until the layout portion can be fixed is at https://gerrit.libreoffice.org/c/core/+/102258
Comment 8 Commit Notification 2020-09-10 05:40:46 UTC
Justin Luth committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d865ae748ae3b1d054051b89938eaef30680e06c

tdf#135943 writerfilter: ignore compat LayoutInCell for txbx

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Justin L 2020-09-10 05:48:28 UTC
(In reply to Commit Notification from comment #8)
> tdf#135943 writerfilter: ignore compat LayoutInCell for txbx

This just avoids creating the compat15 LO problem that is already seen in attachment 165272 [details] from comment 7. But this is NOT how MS Word will see it, so the underlying problem of textbox/frame syncing needs to be fixed first, and then that commit can be reverted.
Comment 10 NISZ LibreOffice Team 2020-12-04 08:58:11 UTC
Created attachment 167818 [details]
Example and its DOCX in Word and Writer 7.2

Looks better in Writer, but not in Word:

Version: 7.2.0.0.alpha0+ (x64)
Build ID: 561e5559bb68242c7f785f0ca3bee3eb12b58963
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win
Locale: en-US (hu_HU); UI: en-US
Calc: CL
Comment 11 NISZ LibreOffice Team 2021-07-04 08:27:07 UTC
Created attachment 173335 [details]
attachment 165272 [details] in Word and current Writer

Still happens with attachment 165272 [details] in:

Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 101ccbd62cd076956754021901486df501aa6054
CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win
Locale: hu-HU (hu_HU); UI: en-US
Calc: CL

Exporting and reloading the original attachment 164488 [details] is no longer broken, however moving the anchor to a different column of the table or outside of the table still breaks it - this should be topic for another bug.
Comment 12 NISZ LibreOffice Team 2021-07-04 08:28:35 UTC
This is one more of the "shape+textframe splits" bugs, changing meta.
Comment 13 Timur 2022-03-14 18:07:09 UTC Comment hidden (obsolete)
Comment 14 Attila Bakos (NISZ) 2022-07-13 13:27:42 UTC Comment hidden (obsolete)
Comment 15 Attila Bakos (NISZ) 2022-07-13 13:30:01 UTC
(In reply to Attila Bakos (NISZ) from comment #14)
> Created attachment 181253 [details]
> Example file in 7.5master

Is this should be the expected result?
Comment 16 Timur 2022-07-13 14:24:06 UTC
Why not, to be the same in LO when open in LO and MSO. 
Only it should on top, without transparency.