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
Created attachment 164488 [details] Example file
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
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
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.
Created attachment 165228 [details] Example compared in Word and LO 7.1
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.
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
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.
(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.
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
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.
This is one more of the "shape+textframe splits" bugs, changing meta.
This one may be resolved in Bug 147921 but it needs a full test in Windows and Linux both for GUI and headless convert, DOC abd DOCX. Bibisect repo is already updated.
Created attachment 181253 [details] Example file in 7.5master
(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?
Why not, to be the same in LO when open in LO and MSO. Only it should on top, without transparency.
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The problem is that SwTextBoxHelper::doTextBoxPositioning does not just copy the absolute position of the laid-out frame, but it re-calculates everything (using very simplistic formulas). Why it would think it needs to do this I don't know. For comment 7's example, the textbox is set to move 6cm to the right of the start of A1. Because it is limited to layoutInCell, the frame is laid out at the right edge of the cell. However, the simplistic textbox doesn't take cell edge into account, and simply applies the specified 6cm. To try to duplicate all of the complex layout calculations into this function is sheer madness. A complete redesign of sync'd textbox positioning is necessary.
Using comment 7, this bibisects to LO 4.4. Steps to reproduce 1.) open 135943_shapeWithText_LayoutInCell1_compat12.docx 2.) mark textbox Frame (aka Position and Size) as "follow text flow" -notice the separation of text and frame as only one part moves. It first started (text moved into cell, frame remained behind) commit d379d18666aa42031359ca8eb34b0021960347ae Author: Miklos Vajna on Wed Jun 18 12:09:15 2014 +0200 oox: import WPS shape with text as shape with textbox Since this patch was just flipping a switch, the logic building up to this is already at fault. Another 4.4 patch set the frame as the positioning object, and the text moved "elsewhere" (where in the UI it changed from "Frame" to "Position and Size". commit 7596e26fd259ce5445212949403e7cd32303b2bd Author: Miklos Vajna on Tue Jun 24 17:47:40 2014 +0200 Add SwTextBoxHelper::findShapes The next (and current/final) change in positioning of the text came in 7.0 with commit 27d04f6dbf38aa28fb7215590d578c4567db5770 Author: Attila Bakos on Thu Mar 19 14:40:36 2020 +0100 tdf#119038 DOCX: fix FollowTextFlow handling