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
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
