Still fine with
Version: 7.0.0.0.beta1+ (x64)
Build ID: 2891e91a513520d68ea2b8c59c14335861a15253
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Still fine with
Version: 7.2.1.0.0+ (x64) / LibreOffice Community
Build ID: 8fdbb8aed1b48734a717d5f98ada566de7204605
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Also in
Version: 7.3.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 7b0aabe71d2455f6f643553a07f1056935cf190f
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

Reproducible in:

Version: 7.4.0.0.alpha0+ / LibreOffice Community
Build ID: 17a4f4d5e4d49189b43e748271d2d4fa330eef9b
CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

Bibisected to:
$ git log --format=reference 253bee65bc24d999c3629a4d503d0fa01b355cfc..3262fc5ef3bde5b158909d11ccb008161ea95519
3262fc5ef3bd (tdf#142304 a.o. Improve wrap margins in docx filters, 2021-05-15)
2ffdd3706792 (tdf#139549 DOCX import: document got modified at import time, 2021-01-16)
67a56b715915 (sw: prefix members of HTMLTableColumn, HTMLTableContext, SwWriteTableCol ..., 2021-06-28)

Whereas the following one seems related:
commit 3262fc5ef3bde5b158909d11ccb008161ea95519
Author: Regina Henschel <rb.henschel@t-online.de>
Date:   Sat May 15 23:40:34 2021 +0200

    tdf#142304 a.o. Improve wrap margins in docx filters

Adding Regina Henschel to cc: would you please take a look? Thanks.

The wrap is determined by a drawing object, which is a custom shape rectangle without fill and stroke. That is "Frame1" in the branch "Drawing objects" in Navigator.
This rectangle has a BoundRect, which is shifted up by 1 (Twips) compared with the FrameRect. You can see both with the "Development tools". There is a second object named "Frame1" in part "Shapes" in the "Object" pane in "Development tools". That is that from branch "Frames". That one from branch "Drawing objects" has "DYNAMIC" in the property "TextWrap".

Because the rectangle has no transformation and no stroke, BoundRect and FrameRect should be the same. The difference happens somewhere in opening the odt document.

MS Office puts differences between bounding rectangle (=BoundRect) and snap rectangle (=FrameRect) into the attributes wp:effectExtend in the file. Without my patch that was not done on export, with my patch LO writes them to file too. MS Office has no UI for that, but uses the values.

On import from docx the values from wp:effectExtend are incorporated into the wrap distance from text, because LO has nothing comparable to "wp:effectExtend". In this case you get a top distance, in UI 0.02mm, which extends the wrap area of the shape so that there is not enough space for the characters of the third text line.

So the problem is not directly in my patch, but the question is, why the bounding rectangle is shifted up on opening the odt-file.

Another question is, whether my patch can/should workaround the underlying problem.

I guess something is off with the file itself.

It has drawing object frame & a image frame on top of each other. Still no clue how this happened. But well DOCX export converts frames to Drawing objects. I obviously used a quite a number of master builds

So the file itself might be an anomaly

Created attachment 177215 [details]
Only Rectangle

The double "frame1" comes in with ODF -> docx -> ODF. But the problem exists with a pure rectangle too, see attachment.

Nevertheless the way an image with caption frame is exported to docx is questionable and needs improvement for better ODF -> docx -> ODF. But that would be a separate issue.

repro 7.6

Dear Telesto,

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