Trouble with curved*Arrow shapes

Regina Henschel rb.henschel at t-online.de
Wed Apr 27 12:10:14 UTC 2022


Hi all,

LibreOffice renders a sequence of command V or of command B not conform 
to ODF (bug 148707). LO connects the first and second arc (and second 
and third and so on) with a line, but V and B are defined to start with 
a moveTo. When I fix that, it becomes visible, that the segments 
definition for curved*Arrow shapes has an error (bug 148714) in file 
EnhancedCustomShapeGeometry.cxx. Fixing this definition is no problem 
and newly imported shapes would be correct then. But LibreOffice has 
written the wrong enhanced-path into the ODF file markup and that is 
used when reading such file, not the segments definition.

The shapes in question belong to the binary MS Office preset shapes 
(mso-spt102, mso-spt103, mso-spt104, mso-spt105). The same looking 
shapes in the Gallery theme "Arrows" are not effected because they are 
of Type "ooxml-*". The binary MS Office arrow shapes are not part of the 
'Arrow' category in our UI.

To get the same rendering as currently done be LO the sequence has to be 
VW or BA. Authors of self-created shapes should have used this, when 
they are designing a shape ODF conform. Therefore I do not care about 
user-created shapes but only about those from binary MS Office.

In XMLEnhancedCustomShapeContext::startFastElement() I could postpone 
GetEnhancedPath() to after the switch (#1057 to #1134) and pass on Type 
to it. Then in GetEnhancedPath itself I could correct the segments 
depending on Type before creating the property (#829). All in 
/core/xmloff/source/draw/ximpcustomshape.cxx.

A different approach could be to not care about existing documents in 
the code. Perhaps provide a macro to repair a shape for those users, who 
are affected.

So what to do? Do you have different, better ideas?

Kind regards,
Regina


More information about the LibreOffice mailing list