tdf#121845 rework custom shape path command U and T

[Regina Henschel]

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 at t-online.de> 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