Hi Miklos,
I have thought about it again. I think, we need nothing new in ODF. We
can decide whether to use our routing or the OOXML routing from the
svg:d attribute.
If the svg:d attribute is missing, we use OOXML routing. MS Office does
not write the svg:d attribute, when it exports to odp. But we have
written it always.
And when there is a svg:d attribute we can count the number of Bezier
curve segments and look whether first and last control vectors are
parallel or orthogonal. See the table below. Only in case of a curved
connector without handle, we need to look in addition how long the first
control vector is.
| parallel | orthogonal
---------+----------------------+--------------------
1 Bezier | LO one handle | LO no handle, vector 2/3 width/height
| OOX NA | OOX curvedConnector2, vector 1/2 w/h
---------+----------------------+-------------
2 Bezier | LO NA | LO two handles
| OOX curvedConnector3 | OOX NA
---------+----------------------+------------
3 Bezier | LO three handles | LO NA
| OOX NA | OOX curvedConnector4
---------+----------------------+------------
4 Bezier | LO NA | LO NA
| OOX curvedConnector5 | OOX NA
---------+----------------------+------------
So a solution could be to add an additional member to SdrEdgeObj and its
SdrEdgeObjGeoData and set it on import. Bringing this to UI and API
would be a second step.
I know, that it needs an additional case in
SdrEdgeObj::ImpCalcEdgeTrack() around line 1504 in svdoedge.cxx. But I
don't know yet, which other places beside import and export have to be
changed.
Kind regards,
Regina
Miklos Vajna schrieb am 09.11.2023 um 09:17:
Hi Regina,
On Wed, Nov 08, 2023 at 02:38:03AM +0100, Regina Henschel <rb.henschel@xxxxxxxxxxx> wrote:
If we are in running LibreOffice we could distinguish two ways by a new
constant in enum class SdrCompatibilityFlag, for example. But how to save
such information to ODF?
Keep path definition as vague as it is now and put the information into
settings.xml?
Add a new value "curveOOXML" to draw:type (19.229.2) to specify a path as in
OOXML?
I expect the settings.xml way would work if we know you won't have both
curve and curveOOXML shapes at the same time in a document. I assume
that can happen, so that's not a good fit here.
Adding a new value to draw:type sounds better, though possibly
"curveOOXML" is a poor name, it would be better to have a
"curveSomething" name that actually describes the new behavior, without
explicitly referring to OOXML.
But quite probably you know this already. :-)
Regards,
Miklos
