Re: Problems with import of shape type 'arc' from binary MS Office

Hi Mark, hi all,

Mark Hung schrieb am 13-Mar-19 um 12:45:
> Hi Regina,
>
> In your first mail you mentioned that MSO has viewbox size 43200x43200,

that is the size of the full ellipse, not of the viewbox.

> while LibreOffice has viewbox size 21600x21600.
> And MSO viewbox only contains the current sector but LibreOffice 
> contains the eclipse.
>
> I think it's correct that you want to make LibreOffice viewbox only 
> contain the current sector. But I think the problem is caused by 
> incorrect conversion of the draw:enhanced-path (see the content.xml in 
> saved odt file) instead of the incorrect viewbox size.

The enhanced-path uses the same kind of commands as in MS Office. (The 
change from W to V is included in https://gerrit.libreoffice.org/68941). 
Only, that no fixed values for start and end point are used but the 
values are calculated. That is necessary for to get adjust handles. It 
seems, that MS Office generates the handles from some internal defaults, 
there exist no records for equation or handles in the original file.

 I think it's
> important to find out why it failed to convert the enhanced-path so that 
> it only contains the sector.

The original file uses 'msopathEscapeClockwiseArc'. That corresponds to 
ODF command V. The current solution translates it directly.

MS Office 365 drops the ability to change the sector, when it converts 
the file from binary format to OOXML. The converted shape has no handles 
and its outline is generated by a Bézier-curve in OOXML.

> Although changing the viewbox size might have the expected effect for 
> the arc shape msoSptArc, but I don't understand why it works and we 
> might also miss the chance to fix the conversion of problematic drawing 
> commands for other custom shapes.

In ODF, the svg:viewBox specifies a rectangle in values of the internal 
coordinate system of the shape. This rectangle is directly bound to the 
rectangle specified by the svg:x, svg:y, svg:width and svg:height 
attributes, which uses values from the outer coordinate system, where 
the shape is anchored. That is the rectangle which corresponds to the 
resize handles in the UI.

From all shapes in MS Office 97, the mso_sptArc is the only one (I have 
tested it), where dragging an adjust handle changes the rectangle of the 
resize handles. I haven't got a MS Office 2003 to test it there. And I 
doubt there exist user defined shapes in binary format.

The 'arc'-shape from a current MS Office 365 does not behave this way. 
Here dragging the adjust handle does not change the rectangle of the 
resize handles. The 'arc'-shape from a current MS Office 365 behaves the 
same, as the shape in LO, which is currently generated from import of 
shape mso_sptArc.

The properties of the mso_sptArc seem to be more like the arc, sector 
and segment from the 'legacy ovals'. But they have different behavior in 
regard to filling. The arc from the example document of tdf#124029 
cannot be expressed by a 'legacy oval'.

You are right, perhaps a more general solution is needed. If the 
solution were so clear, I would not have ask on the list.

Problems are:
MS Office allows positions, so that parts of the shape are outside the 
page area. That allows e.g. a sector to be placed in the corner of a 
page. LibreOffice shows such, if the file is in docx format, but does 
not allow it in odt format.
I can try to change the position information (svg:x, svg:y) so that the 
sector of a mso_sptArc shape will be at the same position as in Word. 
But that works only as long as the entire underlying ellipse is still 
inside the page area.

The layout algorithm in Writer is fragile and implementing positions 
outside the page area for the rare cases of arcs in old binary documents 
looks too dangerous to me. (Besides the fact, that I do not understand 
enough about the algorithm and its implementation.)

Kind regards
Regina