Bug 142433 - FILESAVE DOCX unsuitable wrapPolygon for complex shapes
Summary: FILESAVE DOCX unsuitable wrapPolygon for complex shapes
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Regina Henschel
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shapes Shape-ODF-OOXML-export
  Show dependency treegraph
 
Reported: 2021-05-22 15:08 UTC by Regina Henschel
Modified: 2021-09-10 15:34 UTC (History)
0 users

See Also:
Crash report or crash signature:


Attachments
Document with failing shapes (20.77 KB, application/vnd.oasis.opendocument.text)
2021-05-22 15:08 UTC, Regina Henschel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2021-05-22 15:08:00 UTC
Created attachment 172251 [details]
Document with failing shapes

The attached document contains some shapes, for which wrapPolygon is totally wrong. The shapes are filled 80% transparent, so that you can see in Word, what is rendered behind the shape. Save the document to docx and compare the rendering in Word with the rendering of the original document in LibreOffice.

The relevant code is below #813 in DocxSdrExport::startDMLAnchorInLine.
https://opengrok.libreoffice.org/xref/core/sw/source/filter/ww8/docxsdrexport.cxx?r=c7c6f0af#813
There the wrap polygon is generated from the coordinates in 'Coordinates' in CustomShapeGeometry. This fails in following cases:
a) The shape uses in its path curves. In that case the outline of the shape is not a polygon of the points in 'Coordinates', even if they are all values and not references to formulas.
b) The coordinates are not given by value but by reference to a formula or handle.
c) The shape consists of several subpathes. That is not only the case for the obvious shapes like 'Sun' and 'Callout Cloud'. But it is also the case for shapes with holes and for shapes, which have darken or lighten parts.

I have some ideas that might help to solve the problem. But I have not worked them out and have not tested them:
* Use the method TakeContour() from the SdrObject followed by correctOutmostPolygon() from b2dpolypolygontools.hxx and write out the points of polygon with index 0.
* Make a copy of the object and convert it to polygons (.uno:ChangePolygon). Then take all generated polygons and merge them (.uno:Merge). That might work well with the darken/lighten cases and with holes, but will fail for shapes with distinct parts. Those might need individual methods.
* Look how our rendering finds the contour. (Where is that code?)
* Make a copy of the object and convert it to bitmap. Use the feature "Autocontour" of the "Contour Editor". (Where is that code?)
Comment 1 Dieter 2021-06-07 06:59:43 UTC
(In reply to Regina Henschel from comment #0)
> The attached document contains some shapes, for which wrapPolygon is totally
> wrong. The shapes are filled 80% transparent, so that you can see in Word,
> what is rendered behind the shape. Save the document to docx and compare the
> rendering in Word with the rendering of the original document in LibreOffice.

I confirm it with

Version: 7.2.0.0.alpha1+ (x64) / LibreOffice Community
Build ID: 4a9eef7849a75ba91806886ea9c96d114c8d56f9
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL
Comment 2 Regina Henschel 2021-07-19 13:25:49 UTC
I'll work on it and fix it together with the other wrap problems in DocxSdrExport::startDMLAnchorInline.
Comment 3 Regina Henschel 2021-08-13 18:06:47 UTC
The wrong wrap is fixed with
https://git.libreoffice.org/core/commit/61ef73bb9e06ac7325abc26698314d7e35c164cc
tdf#143432 and more, improve wrap contour export

The fact, that the curved block arrow (type "non-primitive") is exported as rectangle is a different, unrelated bug.