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
