Created attachment 189651 [details] test file with screenshots that show differential behavior The attached file gives a test document and includes screenshots of the problem. 1. Insert some curved arrows into a new document. 2. Save as .docx and open in Word. 3. If saved with Version: 7.2.7.2 (x64) / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 then arrows appear the same (as expected) when opened in Word. 4. If saved with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 218a7650a5cf03f895bed19c68d6f02daec536e9 the curved arrows are NOT reproduced as expected. Screenshots in attached document show the obtained results. Possible regression?
I can confirm with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 0c4913e03e8427a576138601958f2dbf13b8c37b CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Works in 7.2, regression
This seems to have begun at the below commit in bibisect repository/OS linux-64-7.3. Adding Cc: to Bartosz Kosiorek ; Could you possibly take a look at this one? Thanks 78029f8b9e852fad12e7029fa3cbd4663861655c is the first bad commit commit 78029f8b9e852fad12e7029fa3cbd4663861655c Author: Jenkins Build User <tdf@pollux.tdf> Date: Mon Mar 28 12:44:51 2022 +0200 source 6bd85136efe3d3668b59a596d692f65bf0a4982c 132048: tdf#147978 export subpaths individually in custGeom | https://gerrit.libreoffice.org/c/core/+/132048
The problem is in the path definition of the circular arrow in EnhancedCustomShapeGeometry.cxx. It has top-left and bottom-right of the ellipse rectangle exchanged. Only I'm currently not sure whether to correct it there or correct it in the conversion to oox or both. I need some time for testing.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/10c7bc0c824697b92c22bddacd739de9127dc80e tdf#157289 normalize ellipse bounding box in oox export It will be available in 24.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.
It is fixed in the conversion to oox because that it more general and will catch other shape types too, especially user created shapes of "non-primitive" shape type. ODF does not specify, that the first vertex in the B command is top-left of the bounding-box of the ellipse. Thus forcing this for a special shape type is not appropriate.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/1983bccdf2ea620cc1fc2198fd62f286d9ad16e8 tdf#157289 normalize ellipse bounding box in oox export It will be available in 7.6.3. 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.
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-7-5": https://git.libreoffice.org/core/commit/bd17f560a4262c064464cf0b649f537a36bbf2f5 tdf#157289 normalize ellipse bounding box in oox export It will be available in 7.5.8. 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.
Thanks Regina! (also that this fix might be more general). In any case, verified in relation to the OP. Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: cb46ad4c4602fbb6aeab482e9370e31495e12cfe CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: da-DK (da_DK); UI: en-US Calc: CL threaded