https://bugs.documentfoundation.org/show_bug.cgi?id=170767
Justin L <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|[email protected] |[email protected] |desktop.org | Whiteboard| QA:needsComment | --- Comment #1 from Justin L <[email protected]> --- Almost certainly this is based on a bad decision of this being bCompat15. As a pure ODT document, it shouldn't have hit this. In https://gerrit.libreoffice.org/c/core/+/172536 I documented how I chose how to define compat15: AddFrameOffsets was added in 2012 along with ConsiderTextWrapOnObjPos which is used above for bMSOLayout. NICE. That should make it very safe. Any ODT file that is bMSOLayout will have AddFrameOffsets as well (until compat15 removed it on Thu Apr 22 2021). That does mean that any DOCX->ODT created in the last three years might "change" now to more closely match what it should have looked like at the time of conversion. I'm not worried about that. So in this document, settings.xml has ConsiderTextWrapOnObjPos = true, which the (existing) code said was bMSOLayout. That doesn't look wrong... sw/source/core/doc/DocumentSettingManager.cxx: mbConsiderWrapOnObjPos=false; However, it has neither TabOverMargin, nor TabOverSpacing set - and I would have expected one of them if this was a DOCX at some point in time. So something is a bit strange about this 'frame-wrap.odt' I confirmed that ODT defaults to ConsiderTextWrapOnObjPos = false. So this document must have been created where 'Options - Writer - compatibility' changed 'Consider wrapping style influence on object positioning' away from the default. Another interesting thing - when I export this ODT to DOCX format, it exports as compat14 and not compat15. That is because of another Writer compatibility level setting: 'Do not add leading (extra space) between lines of text'. This one is particularly hard to understand because one description is a negative (NoExternalLeading - in Writer Compatibility) and the other one sounds positive (ADD_EXT_LEADING/AddExternalLeading - in settings.xml). AFAICS, ODT defaults to ADD_EXT_LEADING (and again, this particular document changes this value). DOCX export forces compat14 when ADD_EXT_LEADING is disabled. meta.xml says it was created by "LibreOffice/24.2.0.3$Windows_X86_64 LibreOffice_project/da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1" Yay - when I round-trip the file as a compat15, then in MS Word 2024 it looks like what Gabor described. So everything is on the right track, except that this document doesn't naturally export to compat15, so it shouldn't look like compat15. Also worth noting in the commit review is that I said: I can't believe I'm actually considering to submit this layout patch! But all my objections along the way were resolved as my initial coding errors. So now the patch works and passes all unit tests, and I don't have any firm ground left on which to avoid proposing it for acceptance. -- You are receiving this mail because: You are the assignee for the bug.
