improvements on ellipticalquadrant in enhanced path of custom shape

Hi all,

I'm working on tdf#121761 and tdf#121952. The current state is in 
https://gerrit.libreoffice.org/#/c/64817/. It works in principle, but 
there are still some problems.


Problem A
The current implementation has a method GetPoint, which returns a 
tools::Point; and such has integer coordinates. This introduces 
inaccuracy, if you need to use the result in further calculation.

Currently I use GetParameter (which results a double) directly and add 
the needed shift and scaling each time. I think, it would be better to 
have a method for getting a point in double coordinates. Do you agree?

The calculation inside GetPoint is in double and only at last step it 
gets a cast to integer, astonishing for y-coordinate to sal_Int32 and 
for x-coordinate to long. The structure of the calculation seems 
unnecessary complicated to me.

How can I get a method for double point parallel to the existing 
GetPoint? Do I need a new method name? Or is there a way to keep the 
current method name, but different result type?


Problem B
The commands X (ELLIPTICALQUADRANTX) and Y (ELLIPTICALQUADRANTY) draw an 
arc clockwise or counter-clockwise depending on the position of the 
current point and the target point. But the method 
createPolygonFromEllipseSegment from basegfx does only create arcs 
clockwise.

My current solution contains the same idea to generate a 
counter-clockwise arc four times. Not nice. I can put it into a local 
method for these special cases, I can add a new method 
createPolygonFromEllipseSegmentCounterClockWise or I can add a parameter 
to createPolygonFromEllipseSegment to allow generating of 
counter-clockwise arcs. Which way to go?


Problem C
The commands X and Y draw an arc from the "current" point. What to do, 
if a path starts with an X or Y command? The current solution makes a 
moveTo to the target point and continues then. Such continuation might 
be with additional target points for X or Y. The general flow following 
ODF is, that the direction toggles between x-direction and y-direction 
automatically after each point. (That is bug 121952). But what to do, if 
the path is ill-structured and the first parameter point is consumed by 
moveTo? Keep the direction or toggle it?

I cannot look how PowerPoint or Karbon handle this case, because both 
crash on such ill-structured path.


Problem D
How to make a unit test for such patches 
(https://gerrit.libreoffice.org/#/c/64704/1 is another one)? It would 
need to compare a bad rendering with a correct one and it would need to 
be independent from screen resolution. Does a template exist somewhere?

Kind regards
Regina