Created attachment 172202 [details] Example file from Writer with shapes and added text The attached example file contains Writer shapes that were found to be exported incorrectly to docx: their textbox used to be inside their area, but after save they are resized to the bounding rectangles size. Steps to reproduce: 1. Open attached example Writer file. The shapes contain some text written on them. 3. Save as .docx, reopen files Actual results: In docx, the shapes textboxes size and consequently their texts position is incorrect. Expected results: Docx shapes should look like the original .odt shapes. LibreOffice details: Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community Build ID: 91330c503b7eb91d777978018b66890af87cf8f5 CPU threads: 8; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-GB Calc: threaded
Created attachment 172203 [details] The original file saved by Writer to docx
Created attachment 172204 [details] Screenshot of the original and exported document side by side in Writer – page 1
Created attachment 172205 [details] Screenshot of the original and exported document side by side in Writer – page 2
Created attachment 172206 [details] Screenshot of the original and exported document side by side in Writer – page 3
The example shapes do not have a text box, but a simple label text. The segment is not a custom shape at all. In case a custGeom is written, a <a:rect ...> has to be generated. For to get the correct rectangle, it is needed to get the property "TextFrames" from "Path" in CustomGeomety. But currently only the preset shape types l, t, r, b are written: https://opengrok.libreoffice.org/xref/core/oox/source/export/drawingml.cxx?r=af16aa62#3768 https://opengrok.libreoffice.org/xref/core/oox/source/export/drawingml.cxx?r=af16aa62&fi=WriteCustomGeometry#3557 In case of prstGeom there is no need for a <a:rect ...> element. So writing a shape as ooxml-foo (if possible), would solve the <a:rect...> problem. But it has the downside, that reload and export to binary MS formats will loose the shape. And some of our mso-foo shapes do not have a directly corresponding ooxml-shape. It might help to sort the shapes currently in the floater in the UI in categories a) work with l, t, r, b b) do not work with l, t, r, b, but have exactly corresponding ooxml preset shape c) do not work with l, t, r, b and need ooxml custGeom.
Attila Bakos (NISZ) committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/63cd67e5e18f01aca303131e148c80398a181a41 tdf#92525 tdf#142398: fix export of simple custom shapes It will be available in 7.3.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.
*** This bug has been marked as a duplicate of bug 92525 ***
Attila Bakos (NISZ) committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/0cfa76c0a1883289f8406551d0494cc2a30df926 tdf#92525 tdf#142398: fix export of simple custom shapes It will be available in 7.2.0.0.beta2. 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.