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
