Created attachment 174316 [details] Positioning of the top left image side by side in Word and Writer This is split off from bug 37315 The attachment 147135 [details] shows that layout in Word has changed with CompatibilityMode15. In particular the vertical position of the left side images changed: * the top one specifies a negative position, but is aligned to the top of the page, while in Writer it overlaps the top margin of the page, just like in CompatibilityMode <= 14. * the bottom left one is positioned 12.77 cm below paragraph in Word but it does not overlap the bottom margin: however – were this value taken literally by Word – it should since it is anchored to the second paragraph and that is positioned below the top right image. As you can see, there is no 12 cm vertical space between the second paragraph and the top of the bottom left image. In Word with CompatibilityMode<=14 and in Writer the 12.77 cm value is taken literally and the image overlaps the bottom margin a bit. Steps to reproduce: 1. Open attachment 147135 [details] in Word and Writer, observe the positioning of the shapes on the left Actual results: Top left image overlaps the top margin, bottom left margin overlaps the bottom margin. Expected results: They should not overlap the top/bottom margin. LibreOffice details: Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d1f1f546b212ecd651146addeb328806bb270d5f 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
Created attachment 174317 [details] Positioning of the bottom left image side by side in Word and Writer
Created attachment 174318 [details] The original bugdoc from bug 37315 saved in Word 2010 C14 mode for convenience. Same as the original.
Created attachment 174319 [details] The C14 and C15 example files in Word 2019 side by side
Reproducible in: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 7c1bad415ae48635dc67041c413bb7b76a530c22 CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-07-05_06:55:03 Calc: threaded
Dear NISZ LibreOffice Team, 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
I can still reproduce in: Version: 7.6.3.2 (X86_64) / LibreOffice Community Build ID: 29d686fea9f6705b262d369fede658f824154cc0 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
This bug is very confusing because the layout is bad-looking even in MS Word 2013. repro 25.2+ with comment 0's 37315 crop-problem MSO.docx - the skating picture is intruding into the top page margin - the Cathedral Square picture is intruding into the bottom page margin. The horizontal position of Cathedral Square was fixed in 24.8 by commit 838eb1a370b3bc533e81e819ae697222d3da5022 Author: Miklos Vajna on Thu Jun 13 08:04:30 2024 +0200 tdf#161199 sw DoNotCaptureDrawObjsOnPage: capture wrap=none draw objects INTERESTING - note vmklos' remark in the commit message, which is exactly what this bug report is about...: "Note that Word goes a bit further here and even keeps the shape inside the body text area, but that doesn't seem to be a regression, so leave that unchanged for now."
*** Bug 161559 has been marked as a duplicate of this bug. ***
Note that only the vertical margin cannot be overlapped. The horizontal one can. This sounds identical to vertical layoutInCell, where both "page" and "margin" are implemented as "margin". (see https://gerrit.libreoffice.org/c/core/+/171433)
Created attachment 195917 [details] para from_top-positive_compat15.docx: image is 10 inches below the top of paragraph, and 10 inches to the right In this simple example file, if the fly distance was taken literally it would be well off the page. But in MSO 2013 it hugs the right edge of the paper, above the footer area. (In MSO 2010, it hugs the bottom, right corner of the paper - just like LO.) Not surprisingly, this has nothing to do with layoutInCell. Vertically, the image is forced into the page-margin area (PAGE_PRINT_AREA). Horizontally, the image is forced into the page area (PAGE_FRAME). This only applies to the non-page orientations (i.e. line or paragraph). This applies to all the orientations: top/center/bottom/from top. (If it doesn't fit before the bottom margin, it will move the paragraph to the next page - somewhat arbitrarily as this document shows. I would have expected it to move as a second paragraph too, but it didn't move to page 2 until it was the third paragraph. It depends on the image size. As long as there is enough room to be "below" the first line, it stays on the page.) It does not apply to wrap-through flies.
Created attachment 195918 [details] para from_top-positive_compat15.pdf: how it looks in MSO 2019
Created attachment 196071 [details] tdf99004_c15.docx: Word 2013 version of sw/qa/extras/uiwriter/uiwriter4.cxx testTdf99004 has a very nice unit test with tdf99004.docx which is a compatibilityMode14 file, and tests that the two shapes should not overlap. However, simply changing the compatibility mode number to 15 version does cause the shapes to overlap, since the top shape gets pushed below the header area (as would be expected from this bug report). It is useful to note that there is no header.xml in this document, and yet the header restriction is enforced.
Created attachment 196072 [details] 143899_tableAndImage_c15.docx: floating tables are an exception to the rule Apparently tables are an exception to the rule. sw/qa/core/layout/flycnt.cxx's floattable-tab-join.docx is already a good test which ensures the table doesn't spill over to the next page (which it does if the negative offset isn't applied).
Created attachment 196073 [details] 143899_tableAndImage_c15-mso2019.pdf: how it looks in Word 2019
Created attachment 196105 [details] 143899_framePr.docx: framePr also are not limited to the body text area
A patch that fixes it (and results in a layout loop somewhere during unit tests) is https://gerrit.libreoffice.org/c/core/+/172536
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/309aded3145f8ecec9e9af61a3c64804258f8336 NFC prep for tdf#143899: move TextBoxIsFramePr into SwTextBoxHelper It will be available in 25.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/1de6bea27ed36167ec138818607da7b49e92ec4a tdf#143899 compat15 layout: restrict body fly to PAGE_PRINT_AREA It will be available in 25.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/95b173d41fa7a450821d0e69225df3faa899d290 tdf#165040 tdf#143899 compat15 layout: restrict body fly #2 It will be available in 25.8.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.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/45d640fcf5b473acec55ef45503aa56b998c3b8b tdf#165040 tdf#143899 compat15 layout: restrict body fly #2 It will be available in 25.2.2. 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.