Created attachment 161424 [details] missing-path.docx: from ooxmlexport10 - the number is not positioned correctly. The arrow should be almost touching the number, not an inch below it. Based on a PDF comparison, I can see that the position of the textbox/number is what is wrong. I am guessing that LayoutInCell=0 indicates a different anchor position should be used. This document is in 2010 mode. <w:compatSetting w:name="compatibilityMode" w:val="14"/> It is worth noting that if compatibilityMode=15 (2013 mode) is set in this document, then Word 2013 is somewhat similar to how LO is currently showing it, although it is only about a 1/2 inch away. Therefore any fix for this should take into account the compatibilityMode. See bug 77794 comment 17 for inspiration for that. A bibisect is not possible. The textbox was not showing up until LO 5.3 with commit 9d9e5b40c1a6d91323564e60b25ccf04df86db4b Author: Miklos Vajna on Wed Sep 7 22:17:34 2016 +0200 tdf#78727 sw: fix missing textbox text when anchored inside flying table
The 2013 mode version of the document is attachment 161425 [details]
Created attachment 161426 [details] tdf133522_screenshot.png: compare LO and Word with 2010 mode, 2013 mode
I confirm it with Version: 7.0.0.0.beta1 (x64) Build ID: 94f789cbb33335b4a511c319542c7bdc31ff3b3c CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL in comparison with Word 2016
The anchor of the text box of "9" is inside a floating table. That has: - horizontal position: Left of Margin - vertical position: 0.73 cm from Paragraph This is imported as a frame with - horizontal position: From left by -0.12 cm to Page text area - vertical position: From top by 0.73 cm to Margin The text box and the arrow arc are absolutely positioned in Word, those should not be an issue.
Dear Justin L, 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
Also in Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 35787e07b7e83f7dcaa0c67830fcb4eded49c71f CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
The table the textbox is anchored in is a floating table, with .73cm vertical displacement - which accounts for the number 9's downward shift by .73cm. (oh, comment 4 already said all of that.)
*** Bug 157161 has been marked as a duplicate of this bug. ***
I have a patch that fixes duplicate bug 157161's anchoredInCellTextbox2.docx. However, there are too many edge cases where FollowTextFlow/layoutInCell are not supported, or not sync'd, or not handled the same in Writer/Word. https://gerrit.libreoffice.org/c/core/+/157636 * see earlier patchsets for affected unit tests.
*** Bug 157707 has been marked as a duplicate of this bug. ***
Created attachment 195826 [details] 160077_layoutInCell_horiRight_compat12.docx: a horrible related example Contrary to the file name, this one is actually layoutInCell="0" (aka false), and probably is not legitimately compat12 since it has some DML in it. In any case, MS Word opens it without complaint, positioning the image at the top right corner of the table. (note that the right of the table is also the non-table-paragraph/page margin). <wp:positionH relativeFrom="column"> // paragraph <wp:align>right</wp:align> </wp:positionH> <wp:positionV relativeFrom="paragraph"> <wp:align>top</wp:align> </wp:positionV> The problem is that "vertical paragraph" is illegal in this context for some reason (perhaps because it is a block table - not defined inside a w:p), and thus when viewing the "size and position" in MS Word and pressing OK, the image jumps to the top of the page. But all this basically just confirms that both horizontal and vertical need to use the table frame instead of the cell frame as their reference point if not compat15.
Created attachment 195879 [details] 160077_layoutInCell_horiRightB_compat12.docx: goes to right of paragraph, not right of table (In reply to Justin L from comment #11) > But all this basically just confirms that both horizontal and vertical need > to use the table frame... Oops - I did it again. It is NOT the table, but the "paragraph the table is in". If the table is not 100% of the width, then you can see the image outside the table boundaries.
The compat15 document seems have have been fixed in LO 7.1 with commit c9eb53f200225f2ee6ca695e1326843a487aee51 Author: Daniel Arato (NISZ) on Wed Oct 14 15:46:23 2020 +0200 tdf#135198 sw editing: text box fell out of its shape
Created attachment 195956 [details] notLayoutInCell_fromParas_wrapThrough.doc: proof for vertical aspect
Created attachment 195958 [details] notLayoutInCell_fromParas_wrapThrough-mso2010.pdf: how it looks in Word 2010