Created attachment 191049 [details] Compares shape inside table and outside tabe, has screenshot Open attached file. Notice that the text area of the arrow shape is shifted to the right, if the shape inside a table cell. If a new shape is inserted in a table cell in LibreOffice, the text box is at the correct place. Therefore I think, that it is an import problem. It was correct in Version: 7.3.2.2 (x64) / LibreOffice Community Build ID: 49f2b1bff42cfccbd8f788c8dc32c1c309559be0 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: threaded It is broken at least since Version: 7.4.1.2 (x64) / LibreOffice Community Build ID: 3c58a8f3a960df8bc8fd77b461821e42c061c5f0 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL
I see the difference in attachment, but couldn't reproduce My steps: 1. Open attachment 191049 [details] 2. Delete shape inside table 3. Copy shape outside table and paste into table cell (Looks good) 4. Save as docx 5. close and reopen (still looks good) Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5fe2bf914c251009ec4709fa8fdc45c3b53f676b CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded
Created attachment 191347 [details] Screenshot of file generated by LO and then opened in Word Please open the file you have generated in Word. If I follow your instruction I get a file which looks different from the original file in regard of the table.
I can confirm with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2deec946ebfc8f14792e971a354906d1c723164 CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
This seems to have begun at the below commit in bibisect repository/OS linux-64-6.5. Adding Cc: to Attila Bakos ; Could you possibly take a look at this one? Thanks 9bce07baff7148b36600b84bf660bf6da08eff8c is the first bad commit commit 9bce07baff7148b36600b84bf660bf6da08eff8c Author: Jenkins Build User <tdf@pollux.tdf> Date: Tue Apr 7 13:18:12 2020 +0200 source 27d04f6dbf38aa28fb7215590d578c4567db5770 90753: tdf#119038 DOCX: fix FollowTextFlow handling | https://gerrit.libreoffice.org/c/core/+/90753
I'm not sure what comment 4 was bibisecting on. I see the problem Regina stated (the text starting about 0.25cm into the shape) starting in LO 7.4 with commit 6e8ae79176be1c34cadc833c8e521be19455fade Author: Attila Bakos (NISZ) on Thu Feb 17 16:00:01 2022 +0100 tdf#116256 sw: fix textbox position in floating table
(In reply to Justin L from comment #5) > (the text starting about 0.25cm into the shape) That almost certainly will be 0.19cm - the cell's left "border padding" amount.
(In reply to Justin L from comment #5) > (the text starting about 0.25cm into the shape) That will be 0.28cm - the arrow's wrap left "spacing" amount. In MS Word, the Shape Format (Textbox) can set "internal margin" for the textbox (which is text Attributes in LO), and so can "more layout options" specify "distance from text" (which is Edit - Wrap in LO). So in comment 5's patch, auto nLeftSpace = pShape->GetLRSpace().GetLeft(); should be what to get the textbox's internal margin instead of wrap margin?
Created attachment 195758 [details] tdf116256RT2.docx:trying to complicate things and break assumptions - LO doesn't handle this one well.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0c2d2ca64f796b3f3f0bc8a8d123aa1be99414f1 tdf#162211 tdf#158384 layoutInCell: doTextBoxPositioning better 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.