Created attachment 166507 [details] Example file from Word Attached document was reduced from the example file of bug #100920 It contains a shape with absolute horizontal position of 10 cm right of column set in Word. When opened in Writer the shape appears in the correct position, but its Position and Size dialog displays a 3.83 cm value “From left” to “Paragraph area” instead of 10 cm. Clicking OK in this dialog makes the shape jump to 3.83 cm horizontal position. Also: 3.83 inches is 9.73 cm with a bit of conversion/rounding error, so that’s probably what we see here. However making a copy of the shape in Word and setting the horizontal position to another value interoperates nicely, the example document has a copied shape with 2 cm position that is opened correctly. Steps to reproduce: 1. Open attached document 2. Check the Position and Size dialog of the shape Actual results: Horizontal position is 3.83 cm. The copied shape with less text has the correct 2 cm horizontal position. Expected results: Horizontal position should be 10 cm. LibreOffice details: Version: 7.1.0.0.alpha0+ (x64) Build ID: c064766901722082df0d759c95434c1460fcdba5 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: default; VCL: win Locale: en-US (hu_HU); UI: en-US Calc: CL Also in: Version: 6.0.0.3 Build ID: 64a0f66915f38c6217de274f0aa8e15618924765 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: en-US (hu_HU); Calc: CL Version: 5.2.0.4 Build ID: 066b007f5ebcc236395c7d282ba488bca6720265 CPU Threads: 4; OS Version: Windows 6.2; UI Render: GL; Locale: hu-HU (hu_HU - before 5.3 it was 4.09 cm, still not 10 Version: 5.0.0.5 Build ID: 1b1a90865e348b492231e1c451437d7a15bb262b Locale: en-US (hu_HU) Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: hu_HU Before in 4.3 the shape was imported as a frame and it had a correct 10 cm positioning value. Additional Information: Bibisected with bibisect-win32-4.4/ to range: https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=a595879302e26a616131aa0cab5de31bb287b37d..402e0c0a679dd4da2b1767d959be9aa364c1878d
Created attachment 166508 [details] Screenshot of the original document side by side in Word and Writer with the original shapes settings
Created attachment 166509 [details] Screenshot of the original document side by side in Word and Writer with the copied shapes settings
Confirmed using LO 7.1.0.0.alpha1+ (49a39d1abccc61b6dace3e92059ae50a6a2c298d) / Ubuntu. The frame -> text box change in 4.4 happened with the following commit, finished bibisecting using repo bibisect-44max. https://cgit.freedesktop.org/libreoffice/core/commit/?id=7596e26fd259ce5445212949403e7cd32303b2bd author Miklos Vajna <vmiklos@collabora.co.uk> 2014-06-24 17:11:25 +0200 committer Miklos Vajna <vmiklos@collabora.co.uk> 2014-06-24 17:47:40 +0200 "Add SwTextBoxHelper::findShapes" The small change in size in 5.3 happened with the following commit, bibisected using repo bibisect-linux-64-5.3. https://cgit.freedesktop.org/libreoffice/core/commit/?id=c761df1e42fd11acc5fc05b0baacd803c3788ca6 author Miklos Vajna <vmiklos@collabora.co.uk> 2016-10-25 09:05:47 +0200 committer Miklos Vajna <vmiklos@collabora.co.uk> 2016-10-25 09:32:01 +0000 "tdf#84678 DOCX import: fix handling of textbox margins"
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
Created attachment 189441 [details] anchoredInCellTextbox.docx repro 24.2+ I see the same thing with my document. The textbox loads in the same position as before, but now when you look at "Position and size", the wrong distances are shown, and hitting OK moves the textbox. I noticed that this can alter back and forth. I assume it is somehow related to the "maximum distance" allowed before hitting the edge of the page. Try changing the value to some large number (like 10cm) and notice that the UI reduces that number. Press OK, and then open the dialog again, and a different number with be shown, and quite likely a different maximum will also be allowed.
(In reply to Justin L from comment #5) > Change the value to some large number (like 10cm) and notice that the UI > reduces that number. Broken since 7.5.4. bug 157168. Although layout code is nearly impossible to debug, the issue goes something like this: -the code might not have noticed which fly you have opened the dialog for -therefore the valid range where the fly can move is somewhat random. -the current position might not fit in that valid range -therefore the highest/lowest value might be assigned to the display/applied at OK. Identifying the correct fly seems to be solved with https://gerrit.libreoffice.org/c/core/+/156786.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6a24155269d26d1a31a88158154bb4db0c933871 tdf#137595 sw: current fly might not be selected It will be available in 24.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.