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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice




[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux