Bug 133522

Summary:	FILEOPEN: DOCX: LayoutInCell(false): position of textbox incorrect (compat14)
Product:	LibreOffice	Reporter:	Justin L <jluth>
Component:	Writer	Assignee:	Not Assigned <libreoffice-bugs>
Status:	NEW ---
Severity:	minor	CC:	buzea.bogdan, jluth, libreoffice
Priority:	low
Version:	Inherited From OOo
Hardware:	All
OS:	All
See Also:	https://bugs.documentfoundation.org/show_bug.cgi?id=116256 https://bugs.documentfoundation.org/show_bug.cgi?id=157637
Whiteboard:
Crash report or crash signature:		Regression By:
Bug Depends on:
Bug Blocks:	131304, 139532
Attachments:	missing-path.docx: from ooxmlexport10 - the number is not positioned correctly. tdf133522_screenshot.png: compare LO and Word with 2010 mode, 2013 mode

Description Justin L 2020-05-30 10:46:04 UTC

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

Comment 1 Justin L 2020-05-30 10:52:55 UTC

The 2013 mode version of the document is attachment 161425 [details]

Comment 2 Justin L 2020-05-30 11:04:14 UTC

Created attachment 161426 [details]
tdf133522_screenshot.png: compare LO and Word with 2010 mode, 2013 mode

Comment 3 Dieter 2020-06-03 07:12:13 UTC

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

Comment 4 NISZ LibreOffice Team 2020-12-01 14:21:07 UTC

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.

Comment 5 QA Administrators 2023-01-12 03:20:55 UTC Comment hidden (obsolete)

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

Comment 6 BogdanB 2023-04-22 07:25:28 UTC

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

Comment 7 Justin L 2023-05-19 15:24:59 UTC

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.)

Comment 8 Justin L 2023-09-11 20:54:46 UTC

*** Bug 157161 has been marked as a duplicate of this bug. ***

Comment 9 Justin L 2023-10-06 19:21:05 UTC

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.

Comment 10 Justin L 2024-01-20 20:58:36 UTC

*** Bug 157707 has been marked as a duplicate of this bug. ***