Bug 142433

Summary: FILESAVE DOCX unsuitable wrapPolygon for complex shapes
Product: LibreOffice Reporter: Regina Henschel <rb.henschel>
Component: WriterAssignee: Regina Henschel <rb.henschel>
Status: RESOLVED FIXED    
Severity: normal    
Priority: medium    
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Windows (All)   
Whiteboard:
Crash report or crash signature: Regression By:
Bug Depends on:    
Bug Blocks: 108741, 136358    
Attachments: Document with failing shapes

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.