Created attachment 190150 [details]
layoutInCell_line.docx: minimal example - made in LibreOffice

The layout in LO and MSO is currently identical.
That is actually a bad thing because LO is indicating that this is not following text flow. However it should, and MSO does mark it as "layout in cell".

If it was not "layout in cell", then the curve should be seen under the first column, not the second column.

Steps to reproduce: 
1. open layoutInCell_line.docx
2. go to the "Positions and Size" of the curve. It should be "Keep inside text boundaries"

Ahh, this is a coding exception since LO handles "layoutInCell" differently in this case. (LO wants to force the entire shape into the cell, not just affect the anchor offset.)
    if (m_pImpl->m_nWrap == text::WrapTextMode_THROUGH && m_pImpl->m_nHoriRelation == text::RelOrientation::FRAME)
    {
        // text::RelOrientation::FRAME is OOXML's "column", which behaves as if
        // layout-in-cell would be always off.
        m_pImpl->m_bLayoutInCell = false;
    }

Forced on export via:
if (pFrameFormat->GetSurround().GetValue() == text::WrapTextMode_THROUGH
    && pFrameFormat->....GetRelationOrient() == text::RelOrientation::FRAME)
{
// "In front of text" and horizontal positioning relative to Column is ignored
// on import, add it back here.
     bLclInTabCell = true;
}

Created attachment 190156 [details]
notLayoutInCell_line.docx: modified by MSO 2010 - curve should be under first column

Previous comments have shown code that just hard-codes true (on export) or false(on import) values to layoutInCell. However, that isn't a great idea because as this document shows, it should make a difference in layout.

The layout is the topic of bug 157637. This version of the file just shows that we can't just willy-nilly start forcing certain layoutInCell values.

Currently, this hard-coding makes it impossible for us to fix the layout when layoutInCell==false.

Created attachment 190157 [details]
notLayoutInCell_line_mso2010.pdf: how layoutInCell=false ought to look

Confirm

Arch Linux 64-bit, X11
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 9704f61982360ce35983a61cca3fd00bbdf51ab6
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 25 October 2023

ooxmlexport21's tdf153909_followTextFlow.docx is another example.

So we have a dilemma where the offset needs to be calculated based on layoutInCell=true, but that we can't force the shape to be inside the cell (and thus have turned off FollowTextFlow).

The result is that when LO round-trips file, it looks the same in LO, but in 
MS Word the contents have shifted around (at least for old versions of MS Word).

NOT fixing this layout might be the best response, since compat15 tends to always ignore a false value of layoutInCell.

Setting to very low importance. IIUC, these will all be documents created before Word 2013.

Note that layoutInCell does two different things. The big problem with it is that it (only sometimes) forces the fly inside of the cell boundaries. Secondly, it says whether the fly should offset from the cell margins, or from the paragraph-that-the-table-is-connected-to's margins.

*** This bug has been marked as a duplicate of bug 133522 ***