Hi Miklos, hi Thorsten,
Miklos Vajna schrieb am 21-Feb-19 um 13:46:
Hi Regina,
On Tue, Feb 19, 2019 at 08:58:56PM +0100, Regina Henschel <rb.henschel@xxxxxxxxxxx> wrote:
(1) My opinion, how the commands U and T should work, see comments in
https://bugs.documentfoundation.org/show_bug.cgi?id=121845.
The description in the ODF 1.2 spec seems to be a copy of the VML spec
proposal and is not clear.
Seeing that noone replied so far, just some thoughts...
Another source of information might be the drawingML spec, which is
supposed to be able to describe all features VML has. But the first is
part of OOXML strict, so possibly it has a bit better description.
OOXML has the command arcTo. It is not compatible to ODF commands U and
T. That is the reason, why we have introduced a new ODF command G
(=ARCANGLETO), which is currently in drawooo namespace, but will
hopefully be in ODF 1.4.
The implementation in MS Office is surely wrong,
because it sets 0 degree in up-direction.
You mean the ODF filter of MS Office?
Yes, I mean MS Office import filter for ODF.
MS Office avoids command U and T on export to ODF, but use cubic Bézier
curves. It avoids the OOXML command 'arcTo' too, when converting from
"Word 2003 XML". In compatible docx format, it writes only VML, and in
strict docx format, it uses alternative content with one case VML and
the other case OOXML command 'cubicBezTo'.
(2) I have made the case distinction on the draw:type attribute.
I'm not sure, that this is the correct way to go. A different way would be
to add an internal property to shapes, which filter was used on opening.
However that would touch much more parts and might be beyond my skills.
Storing the filter name is not great -- I think loading from MSO formats
and saving as ODF is a frequent use-case. If saving as ODF and reloading
changes how the commands are interpreted, that's problematic.
I see no way to write that, what is possible in VML, with the commands,
that are available in ODF 1.2. The problem is, that the swing angle can
produce several turns.
And handles, equations and modifiers need to be converted too for a true
conversion. Path and equations do not change for static shapes. Export
to ODF will keep the MS-kind values and the draw:type, so that reloading
from ODF goes to the same case as reading the original doc-format.
I have no solution for dynamic shapes, those can be changed by handles.
The handle problem would still exist, if we switched to the new ARCANGLETO.
The original comment in the source was:
// SJ: if the angle was imported from our escher import, then the
// value is shifted by 16. TODO: already change the fixed float to a
// double in the import filter.
The real challenge, however, is not converting the angles in the path,
but adjusting the equations and modifiers and handles.
The current implementation for shapes in OOXML also avoids doing a full
conversions during import. The angle conversion is in
EnhancedCustomShape2d.cxx. I have not yet tested user defined shapes
with handles for that file format. I only have seen, that the problem of
large swing angles is not solved.
From Thorsten from Gerrit:
Line 1595:
That seems a tad brittle? If indeed there's no way to fix that on import, I'd much prefer a separate, explicit marker property on the SvxShape, that the import sets.
Thorsten, I have no idea, where to set it.
Are you afraid that the test 'startsWith("mso") will catch wrong shapes?
BTW, I have only doc-documents with non-preset shapes. Does someone else
has ppt or xls documents, which have non-preset shapes, that lead to
ANGLEELLIPSE on import?
Kind regards
Regina
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
