Description: Editing this MSO file in LO Writer causes the header and footer contents to be corrupted having zero height. Before and after example files are attached. Steps to Reproduce: 1.I open the file labeled BEFORE 2.I deleted one character of text in the main body, not the header or footer, then type that same character again. 3.I save the file as a docx file 4.After reopening the text in the header and footer has zero height and appears to be "gone" to my MSO using colleagues who then get upset. Actual Results: After reopening the text in the header and footer has zero height and appears to be "gone" to my MSO using colleagues who then get upset. Expected Results: After reopening the text in the header and footer should look as they do in the file labeled BEFORE opening in LO Writer. Reproducible: Always User Profile Reset: No Additional Info: This problem has only started happening in the last couple of weeks. So something has changed recently. The colleagues use MSO365 and can be assumed to be up to date.
Created attachment 182457 [details] before and after .DOCX files demonstrating the problem
Created attachment 182458 [details] before and after .DOCX files showing the problem
Confirm, however in my case with different steps: 1. Open attachment 182458 [details] 2. Save 3. File -> Reload 4. Save 5. File -> Reload -> Broken Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: dc92a4d973086ce8a6a5f75ba0f4d4c9ca05537a 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 threaded
Not in Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 229123ccc6f90ebf66b3e659bebbd53f8a9bdd3a 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
No repro with Version: 7.5.0.0.alpha0+ / LibreOffice Community Build ID: e46f9cc4b506c325cbe1060777bbc81fd1630f49 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
(In reply to raal from comment #5) > No repro with Version: 7.5.0.0.alpha0+ / LibreOffice Community > Build ID: e46f9cc4b506c325cbe1060777bbc81fd1630f49 > CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US > Calc: threaded Comment 0 or comment 3 or both
This is a serious problem for me so I upgraded from LO 7.3.5.2 to LO 7.4.1.2 hoping to solve the problem, but the bug was present in LO 7.4 also. If LO 7.5 really has this problem solved how soon will I be able to use it? (As an emergency work around I also installed OnlyOffice Desktop Editors and it did not have this problem.) My MSO using colleagues who receive all these files from me, do not see the flattened zero height textboxes at all, so they have to recreate the lost header and footer text.
This regression started with the following commit, bibisected to the following commit using repo bibisect-win64-7.4 and steps from comment 3. Adding CC: to Tomaž Vajngerl. author Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk> 2022-06-06 22:53:23 +0200 committer Tomaž Vajngerl <quikee@gmail.com> 2022-06-08 11:36:12 +0200 tdf148321: convert OOXML inset values to text distance values
Created attachment 183219 [details] Example without VML The fact, that the problems does not become visible with the first but with the second resave, has its reason in that the shape is a VML shape. And the first resave only converts it to a OOXML shape. The attached file shows the problem with first saving. The problem is not only with shape in header. The attached file has a text box in body area and one in header. It seems to be a problem in saving. Opening has the padding values as defined in the file. The problem does not only exist in Writer, but in Impress too. Example file will follow.
Created attachment 183220 [details] Same problem with pptx
The problem is in https://opengrok.libreoffice.org/xref/core/oox/source/export/drawingml.cxx?r=3d236177#3326 pCustomShape->TakeTextAnchorRect(aAnchorRect); If the nominal text area rectangle has height 5000, the top distance is 1500 and the bottom distance is 2500, then TakeTextAnchorRect gives the height of the remaining area after subtracting the distances: 5000-1500-2500=1000 TakeTextAnchorRect is surely not the rectangle do you want. You get the text area rectangle as defined in the shape geometry from the EnhancedCustomShape2d of the shape. You can use the seqTextFrames[0] or the GetTextRect() method. The latter considers flipping, but that effects only the position and not the height of the rectangle. Please keep in mind, that this part of code is not only used when you resave an imported OOXML-document, but also when an ODP-document is exported. There is another error in #3320, where Width is used instead of Height. But that has no impact as long as the code part works with custom shapes.
Or use UNO. The needed rectangle is in "TextFrames" in "EnhancedCustomShapePath".
I think in addition the 'then' part in #3333 and #3334 is wrong. Reasoning is here: If the top and bottom indents are set so, that the calculated top edge of the resulting effective text area is below the calculated bottom edge, then LibreOffice normalizes the resulting rectangle. Example was LO does: Nominative text area rectangle height = 4cm, top indent = 3cm, bottom indent = 5cm. That means, that the calculated bottom edge (nominal bottom edge - bottom indent = height - bottom indent) is 1cm above the nominative top edge and the calculated top edge is 3cm below the nominative top edge. This is normalized so that the effective top edge is 1cm above the nominative top edge and the effective bottom edge is 3cm below the nominative top edge. Since bottom indents are measured from the nominative bottom edge, the effective used indents are top = -1cm and bottom = 1cm General: if (top + bottom >= height) then new top = height - bottom new bottom = height - top The new indents create a regular rectangle and can be directly exported to pptx. Export to docx has additional problems: Word does not show overflowing text and Word does not accept negative indents, although such can be described in OOXML file format. So perhaps export to docx needs special handling in case calculation of the indents results in such cases. The special problem with the docx document here should be already solved when the correct height is used, because it then no longer enters the if-then part.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/933768ffcd8617942f45481de77e656ded9dcfe2 tdf#150966 oox export avoid bottom above top for text area It will be available in 7.5.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.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/59b44e72f46021c070095a75a0d7e0ae12c43399 tdf#150966 oox export avoid bottom above top for text area It will be available in 7.4.4. 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.
*** Bug 152633 has been marked as a duplicate of this bug. ***